bneradt commented on code in PR #9366:
URL: https://github.com/apache/trafficserver/pull/9366#discussion_r1145339335
##########
proxy/http2/Http2Stream.h:
##########
@@ -295,6 +350,20 @@ Http2Stream::set_receive_headers(HTTPHdr &h2_headers)
_receive_header.copy(&h2_headers);
}
+inline void
+Http2Stream::reset_receive_headers()
+{
+ this->_receive_header.destroy();
+ this->_receive_header.create(HTTP_TYPE_RESPONSE);
Review Comment:
In short, the `_receive_header` is what is parsed from the wire, either
request headers on the client side or response headers on the origin side, and
the parsing logic (`http2_decode_header_blocks`) seems to only work if we do
not "create" this with `HTTP_2_0`.
---
The `_receive_header` value is actually always always created uncategorized,
not just here. See the also stream constructor here:
https://github.com/apache/trafficserver/pull/9366/files#diff-863a3cab1dd2ae149f1b54381d873d5291fb94f8aef77df7afb9b5f6a2d5dc61R66
See also the inbound version a few lines after that.
It is configured with the expected version through later processing of
content received from the client or origin via decode_header_blocks. To explore
your comment, I played around with an autest and gdb to see what happens if I
initialize the `_receive_header` with `HTTP_2_0` and it seems like we mishandle
pseudo header fields because they show up multiple times in the buffer. This
causes us to fail a basic parsing check that says we should only have 4 or 1
pseudo headers, depending upon whether we are parsing a request or a response.
Note by contrast that our `_send_header` does not have this parsing problem
because it is always explicitly crafted by us. As a result, `_send_header` is
always created with `HTTP_2_0`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
