maskit commented on code in PR #11611:
URL: https://github.com/apache/trafficserver/pull/11611#discussion_r1693542259
##########
src/proxy/http3/test/test_Http3FrameDispatcher.cc:
##########
@@ -225,6 +261,45 @@ TEST_CASE("control stream tests", "[http3]")
free_MIOBuffer(buf);
}
+// This test needs to run without an enforcer due to a frame counting bug.
+// Add a ProtocolEnforcer handler to reproduce.
+TEST_CASE("padding should not be interpreted as a DATA frame", "[http3]")
+{
+ Http3FrameDispatcher http3FrameDispatcher;
+ Http3MockFrameHandler handler;
+
+ http3FrameDispatcher.add_handler(&handler);
+
+ MIOBuffer *buf = new_MIOBuffer(BUFFER_SIZE_INDEX_512);
+ IOBufferReader *reader = buf->alloc_reader();
+ uint64_t nread = 0;
+ Http3ErrorUPtr error = Http3ErrorUPtr(nullptr);
+
+ uint8_t input[] = {
+ 0x40, 0x04, // Type
Review Comment:
This is an interesting input. If this were for QUIC frame type, it'd be
protocol violation.
RFC 9000 says:
> Values do not need to be encoded on the minimum number of bytes necessary,
with the sole exception of the Frame Type field; see [Section
12.4](https://datatracker.ietf.org/doc/html/rfc9000#frames).
> The Frame Type field uses a variable-length integer encoding (see [Section
16](https://datatracker.ietf.org/doc/html/rfc9000#integer-encoding)), with one
exception. To ensure simple and efficient implementations of frame parsing, a
frame type MUST use the shortest possible encoding.
I don't see a similar limitation on RFC 9114 (HTTP/3).
--
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]
