Skip to content
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

RestTemplate doesn't consistently tolerate unknown HTTP status codes [SPR-15978] #20529

Closed
spring-issuemaster opened this issue Sep 19, 2017 · 12 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Sep 19, 2017

Darija Radchenko opened SPR-15978 and commented

I'm really sorry, I fill confused about this, but as listed here we are enable to handle custom http status codes already... But I'm still getting
IllegalArgumentException: no matching constant for [230] caused in MessageBodyClientHttpResponseWrapper.hasEmptyMessageBody().
I'm using API that responses 230, 240 codes etc... Can you please provide some example or guide me somewhere I can find the solution?

Spring Framework version 4.3.11


Affects: 4.3.11

Issue Links:

  • #11418 RestTemplate throws IllegalArgumentException when HTTP status is not in the HttpStatus enum
  • #14042 Unknown status codes (i.e. not in HttpStatus enum) prevent HttpClientErrorException and HttpServerErrorExceptions from being raised
  • #18779 ResponseEntity should allow the usage of unassigned HTTP status codes
  • #20656 DefaultResponseErrorHandler.hasError doesn't tolerate unknown status codes
  • #20918 RestTemplate.ResponseEntityResponseExtractor doesn't tolerate unknown status codes
  • #21971 RestTemplate does not throw exception for custom error codes
  • #20622 Returning non-standard HTTP status code causes exceptions on WebFlux
  • #21145 DefaultResponseErrorHandler wastes the body of a response with an unknown status
  • #21359 Improve handling of unknown status codes by WebClient

Referenced from: commits 4cbef27, 038af9a, 18a3322

Backported to: 4.3.12

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 19, 2017

Juergen Hoeller commented

I've extended the scope of this issue a bit since it's not just MessageBodyClientHttpResponseWrapper but also ResponseEntityResponseExtractor and DefaultResponseErrorHandler which are not entirely tolerant towards unknown HTTP status codes.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 20, 2017

Darija Radchenko commented

Maybe I can configure RestTemplate to use some body extractor that will let me avoid these errors?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 20, 2017

Juergen Hoeller commented

I've done a full revision of the affected code for 5.0 (introducing a lenient HttpStatus.resolve method and will backport a more minimal version for 4.3.12 (calling getRawStatusCode and/or defensively catching HttpStatus.valueOf exceptions where necessary). This should hopefully work for your purposes out of the box then.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 30, 2017

Darija Radchenko commented

Thank you very much! I tested it on a Spring 5 and it works without any additional configuration. Cheers!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Patrik Steuer commented

Will this fix be available for 4.3.1x aswell?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Juergen Hoeller commented

This should work fine in 4.3.12 already. Have you encountered any recent issues there?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Patrik Steuer commented

It didn't work for me. The related DefaultResponseErrorHandler in the relaese tag does also not contain your change, atleast what I see on github https://github.com/spring-projects/spring-framework/blob/85aab388f0a8f3464fb85030faf45e3deb22a094/spring-web/src/main/java/org/springframework/web/client/DefaultResponseErrorHandler.java

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Juergen Hoeller commented

Ouch, indeed. The backport included the MessageBodyClientHttpResponseWrapper etc changes but only minor refinements to DefaultResponseErrorHandler, not treating hasError properly... While we cannot do a full backport of 5.0's variant here, we should at least leniently handle unknown status codes in hasError there.

Could you please create a separate JIRA issue for this? I'll sort it out for 4.3.13 then.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Juergen Hoeller commented

I've created #20656 myself, specifically for DefaultResponseErrorHandler.hasError. The fix will be in the upcoming 4.3.13.BUILD-SNAPSHOT; please give it a try if you have the chance...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2018

Anika Solanka commented

Hi, I'm using version 4.3.13 and it seems that the ResponseEntityResponseExtractor in this version also has a problem with unknown HTTP status codes. It is calling response.getStatusCode() which throws IllegalArgumentException for unknown status codes.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2018

Juergen Hoeller commented

Anika Solanka, indeed, this looks like one more case that we need to backport to 4.3.x there. This seems to work fine in 5.0.2, so let's simply backport that ResponseEntityResponseExtractor variant to 4.3.14. Could you please create a separate JIRA issue against 4.3.13 for your particular case?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2018

Anika Solanka commented

@Juergen Hoeller I've created #20918

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.