ServerResponse should allow the usage of unassigned HTTP status codes [SPR-16366]

[spring-projects-issues]

Jiří Pauer opened SPR-16366 and commented

Hello,

the current implementation of the ServerResponse does not allow the usage of unassigned HTTP status codes, because of the HttpStatus enum which contains only IANA registered HTTP Status codes.

But the HTTP specification allows the usage of new/extension/unassigned status codes. See: http://tools.ietf.org/html/rfc7231#section-6 and http://tools.ietf.org/html/rfc7231#section-8.2.2
Unfortunately, custom status codes are sometimes used by RESTful APIs.

It would be nice if the ServerResponse would allow custom status codes. The ServerResponse needs a constructor or builder method which excepts custom status codes.

The IANA list shows the codes which are unassigned:
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

---

Affects: 5.0.2

Issue Links:

• Returning non-standard HTTP status code causes exceptions on WebFlux [SPR-16073] #20622 Returning non-standard HTTP status code causes exceptions on WebFlux
• ResponseEntity should allow the usage of unassigned HTTP status codes [SPR-14205] #18779 ResponseEntity should allow the usage of unassigned HTTP status codes
• No support for non-standard HTTP status codes in reactive ClientHttpResponse [SPR-16748] #21289 No support for non-standard HTTP status codes in reactive ClientHttpResponse

Referenced from: commits 9623cde

[spring-projects-issues]

Juergen Hoeller commented

Indeed, the underlying ServerHttpResponse abstraction supports this already... and so does ResponseEntity in Spring MVC. The functional WebFlux usage model should join the club here.

[spring-projects-issues]

Jiří Pauer commented

Perfect.

[spring-projects-issues]

Juergen Hoeller commented

Status codes can be specified as int values on all functional builder variants now, along the lines of ResponseEntity and co.