-
Notifications
You must be signed in to change notification settings - Fork 844
Dechunk chunked contents on HttpTunnel if client protocol is HTTP/2 or HTTP/3 #5901
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
Conversation
|
|
"Hide whitespace changes" would show the real changes clearly. |
|
So if the http/1.1 origin returns a chunked response, we would fail to deliver it to a HTTP/2 or 3 client with this change? What about a HTTP/2 client that sends a post with no content length for the post body? |
HttpTunnel does de-chunk the chunked response from the origin server and gives it to HTTP/2 or HTTP/3 TXN. From HTTP/2 and HTTP/3 TXN, it looks a normal response without a Content-Length header.
I think this change affects the response side only. Because the action of Http2Stream chunk_handler is DECHUNK. I'll make sure. |
3b4ed53 to
c1a8fb8
Compare
|
Pushed new commit using |
|
I did a test with nghttp and Also, Test Case 6 of http2.test.py covers this trafficserver/tests/gold_tests/h2/http2.test.py Lines 153 to 160 in 92d4ef1
|
5b5df90 to
e785557
Compare
e785557 to
f8d0151
Compare
|
@vmamidi PTAL. Rebased on the latest master to resolve conflicts. |
|
Cherry-picked to v9.0.x branch. |
Prior to this change, HTTP/2 has its own ChunkedHandler and do de-chunk in Http2Stream. But think about HTTP/1.0, it doesn't support chunked transfer coding either, but HttpTunnel can handle it correctly.
HttpTransact::handle_response_keep_alive_headers()setHttpTransact::ConnectionAttributes::receive_chunked_responsedepends on the HTTP version and configs, but the conditions doesn't check the HTTP/2 or HTTP/3 correctly.Mark as draft PR for discussion & testing.