On 06/05/2021 16:06, Christopher Schultz wrote:
On 5/6/21 09:36, Mark Thomas wrote:
On 06/05/2021 13:33, Christopher Schultz wrote:
Leon,
On 5/6/21 06:25, Leon Atherton wrote:
We are seeing that Firefox triggers the HTTP2 overhead protection
with multipart file uploads. About 1MB is uploaded before overhead
protection is triggered. I believe a few weeks ago Chrome was
triggering this too, but it looks like a recent update may have
resolved it.
This is on Tomcat 9.0.45 (though it applies to earlier versions
too) using the org.apache.coyote.http11.Http11NioProtocol connector
with upgrade to org.apache.coyote.http2.Http2Protocol.
With http2 debug logging enabled, there are occasional Payload size
[1] interspersed between larger payloads, though it appears to be a
couple of back-to-back Payload size [1]'s which may be triggering
the org.apache.coyote.http2.ConnectionException: Connection [0],
Too much overhead so the connection will be closed.
I've found earlier Tomcat conversations which seem to indicate it's
a client issue. I've searched through the Firefox bug tracker but
have not found anything that looks like this (feels like looking
for a needle in a haystack).
Is this a known issue in Tomcat or Firefox? It can be resolved by
disabling the protection or potentially just tweaking the config
values, but if it's a known Firefox issue I'd like to know if
something has been raised on their bug tracker I can follow?
Nothing in the tracker that I know of off-hand, but there is this
informative answer on SO by markt which may help you a little:
https://stackoverflow.com/a/61454503/276232
Using the information in that answer may allow you to reconfigure
your server to allow Firefox's behavior.
It's probably worth us taking some time to adapt markt's SO answer
there into a whole section on "Protocol Abuse and Protection
Features" in the HTTP/2 configuration guide.
There is an open issue for Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=1000809
ACK
but there hasn't been much movement.
I'll add something to my TODO list to see what can be done to avoid
false positives like this as it looks like short sequences of small
packets can occur depending on how the client buffers data.
Maybe a tweak to the default settings can improve things for "the
status quo" for current web browser behavior.
Thanks guys. I'm currently unable to reproduce the problem in Chrome
(not seeing any 1 byte payloads). I thought it reproduced a few weeks
ago, but perhaps I'm misremembering.
Firefox's market share isn't what it was, but it would be good if this
could work out of the box - either by tweaking the Tomcat code or
default config to prevent the false-positive or opening a ticket so the
Firefox team know what to fix.
Happy to help with the latter, though I'd need some assistance to
explain the problem and expected solution. I could bore you to tears
with the ins and outs of the PDF spec, but HTTP2 is not one of my
specialist subjects.
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
