-
Notifications
You must be signed in to change notification settings - Fork 38.5k
ResponseEntity should allow the usage of unassigned HTTP status codes [SPR-14205] #18779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Juergen Hoeller commented Since 4.1, there is already a |
Robert Winkler commented Hi, |
Juergen Hoeller commented I've implemented this behind |
Robert Winkler commented Thank you very much for your work and fast feedback! We are using Spring Boot 1.3.3 and the Spring IO Platform 2.0.3. |
Juergen Hoeller commented We're going to co-release 4.3 RC2 and 4.2.6 next week, with 4.2.6 essentially just containing bug fixes and log refinements. 4.3 GA is scheduled for June 1st, so not far away either. BTW, the JIRA roadmap panel is always up to date with respect to our current target dates. From my perspective, this kind of change is at home in 4.3, going through a release candidate and then GA in about a month anyway. After all, there could be subtle regressions such as somebody expecting an exception from trying to set an unknown status code, which is ok for a 4.3 but arguably not for a 4.2.x release. So please give the upcoming 4.3 RC2 a try in your integration tests. If any issues remain (in particular with respect to status code handling in the various code paths in Spring MVC), let me know ASAP. Let's make sure that 4.3 GA fully works for you then. |
Robert Winkler commented Yes, you are right. Its a non backwards-compatible change and should not be part of 4.2.6. |
Syed Wasim Ali commented Say, an implementation needs to respond with a 438 "Invalid Identity Header". ResponseEntity.status(int) takes care of setting the http status code. What is the expected string representation for the supposed custom status code? Is there a way to influence the string representation outcome? |
Juergen Hoeller commented Through the Servlet API, all we can do is to delegate to |
Robert Winkler commented
ResponseEntity.status(int, String) method which results in a HttpServletResponse.sendError(int, String) ? |
Juergen Hoeller commented
|
Robert Winkler commented True |
Syed Wasim Ali commented
|
There is a possibility to return unnassigned error status using ResponseEntity: |
|
That's not true.
You can use |
Ahh I see. Thank you very much! |
Robert Winkler opened SPR-14205 and commented
Hello,
the current implementation of the ResponseEntity 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 ResponseEntity would allow custom status codes. The ResponseEntity 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: 4.2.5
Issue Links:
Referenced from: commits d06188e
0 votes, 6 watchers
The text was updated successfully, but these errors were encountered: