Dechunk chunked contents on HttpTunnel if client protocol is HTTP/2 or HTTP/3#5901
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.