--- Comment #7 from Mark Thomas <> ---
Take a look at the following lines in the log:

Connection [1], Stream [7], Frame type [DATA], Flags [0], Payload size [...]

It looks like there is some buffering going on.

The first 6 data frames are 5x2852 bytes and 1x2124 bytes for a total of
exactly 16k.

The first 24 packets are 20x2852, 3x2124 and 1x2123 for a total of 64k-1. The
25th packet is 1 byte giving a total of 64k.

A similar (but not completely identical pattern) follows for the rest of the
upload. It looks like the library you are using has various internal buffers
and what you are seeing (in terms of data packet size) is the result of
interactions between those buffers (I'm assuming there is no HTTP/2 proxy
between the client and Tomcat else things will get more complicated).

Small HTTP/2 packets are inefficient. Lots of them are considered to be abusive
and in some servers (not Tomcat) result in a DoS. Tomcat has expanded its
overhead protection to protect against such abusive traffic. The default
settings considers any non-final DATA frame of less than 1024 bytes abusive.
The smaller the DATA frame, the more abusive it is considered.

I'd recommend opening an issue against the library you are using as it could be
argued it should be sending fewer, larger HTTP/2 frames.

It could also be argued that Tomcat should use a lower overheadDataThreadhold.
However, the counter argument is that a lower threshold is only required for
inefficient clients. Where inefficient becomes abusive is an interesting
question and the answer will vary from server to server. As I said, in Tomcat's
case it is never abusive, only inefficient, but we want to encourage clients to
be efficient.

I'm leaning towards leaving the default as is for now but is is definitely
something we should keep an eye on as more users pick up the latest 9.0.x and
8.5.x releases. If we see a lot of issues like this then we may need to review
the default. I'll leave this open for now but I am leaning towards resolving it
as some form of "not a Tomcat issue".

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to