-
Notifications
You must be signed in to change notification settings - Fork 38.9k
Description
Arjen Poutsma opened SPR-15486 and commented
Currently, we throw a WebClientException for 4xx and 5xx status codes in ClientResponse.bodyToMono(Class) and ClientResponse.bodyToFlux(Class) (but not ClientResponse.body(BodyExtractor). The underlying thought here was that the response format of a 4xx or 5xx error typically does not take the same form as a "regular" 2xx response. Now that we have the ResponseSpec in WebClient, let's revisit this handling of 4xx and 5xx status codes on the client side.
I think the rule to throwing an exception should be simple: if there is no way for the user to get the response status code, then a WebClientException should be returned. If there is a way to get to the status code, then we should not return an exception.
In our current WebClient, this rule would bring the following changes:
WebClient.ResponseSpec.bodyToMonoandbodyToFluxshould returnWebClientExceptionwhen the response status code is 4xx or 5xx.WebClient.ResponseSpec.bodyToEntityandbodyToEntityListshould not return an exception in these cases, because you can get access to the status code throughResponseEntity.getStatusCode().ClientResponse.bodyToMonoandbodyToFluxshould not return an exception, as theClientResponseexposes the response status code throughstatusCode().
All other WebClient/ClientResponse methods should keep their current behaviour.
Issue Links:
- ResponseSpec#toEntity(...) fails when response status code is 5xx [SPR-15739] #20295 ResponseSpec#toEntity(...) fails when response status code is 5xx
- Simplify access to request/response object in WebClient [SPR-15294] #19860 Simplify access to request/response object in WebClient
Referenced from: commits 4a8c99c, 0e7d6fc
1 votes, 3 watchers