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
Gateway should handle header 'Expect 100-continue' compliant with rfc2616 #1337
Comments
This is seriously very weird behaviour. We have spring cloud gateway in production environment and for clients which send
|
I believe this is blocked by the reactor netty issue listed above. |
@spencergibb Reactor Netty will respond automatically with In Spring Gateway I see the following: Line 147 in 73fd528
In the implementation the incoming data is requested always without checking whether there is |
To document, So it still looks blocked but at the framework level now @rstoyanchev |
That is not an actual call but deferred initialization in case of a call to |
I'm able to send a |
Is there any other work around in springboot to handle the Expect: 100-continue header. |
From issue description:
So you can simply add route filter that removes
or
|
@spencergibb gateway sends 100 Continue, but also for the final response. I have Wiremock configured to return 201. In case of direct call to Wiremock:
In case of call through gateway, two 100 Continue are returned and connection timeouts:
|
I just updated spring-boot to version 2.4.3 which depends on reactor-netty version 1.0.4 and netty version 4.1.59
|
That is strange, because my experiment shows that spring-boot version 2.4.3 & spring cloud version 2020.0.1 fixes the problem The problem is still visible for spring-boot version 2.3.9.RELEASE and spring cloud Hoxton.SR9 I vote for close the problem |
I reckon I haven't given enough details about what I'm trying to do. |
@paskos I'm going to say your issue is different than the original intent of this issue. Can you post your filter? |
ExpectContinueGatewayFilterFactory I configured it in the gateway's default filters:
I found the changes in behaviour thanks to an integration test in my gateway that uses wiremock to simulate a downtstream service. When my gateway depends on spring-boot version 2.4.2 and spring-cloud 2020.0.1 my test passes. |
This might be related to this fix reactor/reactor-netty#1492 |
Thank you for the link. |
Currently we are working on a project using Spring Cloud Gateway with dynamic routing and custom load balancing. We faced the same issue and after some investigation we realized that as michalod said in this comment: #1337 (comment) The 100-continue feature works perfectly in Spring Cloud Gateway with the latest version of related dependencies. So I think this issue can be closed. And a late response to paskos:
This is wrong behaviour because if the mobile game requests your gateway with Expect: 100-continue header without Body, then it keeps alive the connection and waits for a response. If the status of the response is 100 Continue, then the mobile game tries to send the rest of the request (actually the Body) in the same TCP connection then waits for a final response (for example: 200 Ok). If the gateway do not pass the request, then the mobile game will hang until timeout. If you would like to reject the requests from mobile games which contains Expect: 100-continue header then in accordance with the RFC standards your gateway has to respond 417 Expectation Failed. If the mobile game implemented the RFC properly then it will send the full request again without Expect header. Here is the code you can use in your custom ExpectContinueGatewayFilterFactory if you want to implement this way.
this code is also a workaround for Spring Cloud Gateway apps using spring-boot version before 2.4.3 if Client hangs in the 100-continue flow. |
This clearly violates https://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1. If the proxy cannot handle the expect handle it must ask the origin. So I expect the API gateway to forward all request headers to the origin server if it cannot make a decision based on the headers. |
Steps to reproduce problem
Target server: Spring Boot 2.1.8 (Tomcat)
Cloud gateway: Greenwich SR3
When target server is called directly:
curl localhost:8080/put -X PUT -H 'Expect: 100-continue' -d x=foo1 -v
communication flow is OK
Expect: 100-continue
100-continue
hello
When target server is called through gateway:
curl localhost:8082/put -X PUT -H 'Expect: 100-continue' -d x=foo1 -v
communication flow is not OK. My wireshark investigation
Expect: 100-continue
to gateway100-continue
100-continue
to gatewayhello
100-continue
to clienthello
but it is not forwardedResponse
100 Continue
is received 2 times - once generated by gateway itself, second forwarded from target server, but true response never reach client.Worth to notice that workaround is filter our header 'Expect 100-continue` when gateway forwards request to target server
The text was updated successfully, but these errors were encountered: