spring-framework
spring-framework copied to clipboard
spring-projects
Http 307 redirection is not working for POST,PUT with body when we used WebClient reactive with Jetty HttpCLient over HTTP/2.
Affects: 5.3.21
When we are using Spring reactive Webclient + jetty httpclient we are unable to redirect for HTTP 307 status code and with POST/PUT request body. we are getting exception "Multiple subscriptions not supported on AsyncRequestContent"
Also this exception is not coming if we are not sending body with the POST/PUT request.
You can refer the code snippet in the below stackoverflow link.
https://stackoverflow.com/questions/74111474/http-307-redirect-fails-for-put-post-calls
Why this issue closed as Jetty HttpClient is working fine and issue comes when spring webclient in reactive mode is used with httpclient.
It looked like this was identified as a Jetty issue, I see that now this cannot be reproduced on the Jetty side. Reopening.
Adding more details to the ticket.
The HTTP 307 redirection works with only Jetty HttpClient as the request is reproducible as explained by Jetty team.
Output
But if we use Spring WebClient with Jetty HttpClient it fails after HTTP 307 redirection as the request is not reproducible and gives error "Multiple subscription not allowed on the request"
Failure logs spring307.log
Jetty's StringRequestContent seems to be reproducible in nature after 307 redirect , whereas BodyInserters.fromValue of Spring content is empty after 307 direct and might be causing the issue.
I think this has been explained very well by this comment. We're operating with reactive Publlisher here and from a client perspective, we have zero guarantee that the request input can be "replayed". In your sample the body is a plain String, but the byte could come from a remote server response or any type of non-replayable stream.
To me, the easiest way to properly deal with this right now is to configure httpClient.setFollowRedirects(false);. This will prevent the client from following automatically redirects and you can be more explicit about it. I've tested this approach and it works.
Note that using the exchange() method can lead to a whole lot of other problems and this is why it's deprecated as shown in your IDE.
I'll keep that issue opened for the time being because the team should discuss a few things:
- How do other clients behave in this case? Do they also try and re-send the request body for HTTP 307 responses?
- Should we update the default Jetty client configuration to not follow redirects by default?
- Is there anything we can do to help with the "replayable nature" of requests or should we document this limitation?
@bclozel
Adding details for your point
How do other clients behave in this case? Do they also try and re-send the request body for HTTP 307 responses?
We tested 307 redirection with webclient+netty and that seems to be working fine.
Output
Maybe this is a issue with the implementation of ClientConnector of Jetty. JettyClientHttpConnector
We do see code to convert Flux to Buffer.
@sanjerai code in images is unhelpful for copy and paste, searching, and doesn't add any value in this case over GitHub markdown code formatting.
Please, provide an actual sample to run.
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
@rstoyanchev all code snippets are attached on below mentioned stackoverflow post for reference 307 redirection failure
- Redirection works with Jetty HttpClient
- Redirection works with Spring Webclient + Netty HttpClient
- Doesnt work with Spring Webclient + Jetty HttpClient
Logs also attached in above link.