https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #7 from Mark Thomas <ma...@apache.org> --- 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
