|Summary:||tomcat 8 fails with non standard HPACK receiver size|
|Product:||Tomcat 8||Reporter:||patrick mcmanus <mcmanus>|
|Component:||Connectors||Assignee:||Tomcat Developers Mailing List <dev>|
Description patrick mcmanus 2016-09-26 13:46:29 UTC
Both firefox 52 (nightly) and Chromium Canary have changed their HTTP/2 stacks to allow the peer to use a 64KB dyanmic HPACK table. (the peer can continue using the default 4KB if it likes, this is just an advertisement that says the client will allow it). Tomcat crashes or at least fails to connect with this SETTING in both browsers. see https://bugzilla.mozilla.org/show_bug.cgi?id=1305321
Comment 1 Remy Maucherat 2016-09-26 14:49:41 UTC
I don't think you need to create so many BZs in various places about this. I also read elsewhere "If you've got anybody to reach out to wrt tomcat, that would be helpful.". This must be avoided at all costs, we do read bug reports just fine when they are accurate, we don't need direct spamming. So ... "Tomcat crashes" Can we get the JVM dump ? "or at least fails to connect with this SETTING in both browsers" Ah ok, so I guess it doesn't crash then. I guess enabling debug logging was probably not an option :) Reading the Tomcat code looks fine for me, the header size from the client settings frame should be used (indeed 8kb and 16kb are working according to the info in the other bug reports, while 32kb and 64kb would not). Odd at this point. We'll look at it eventually.
Comment 2 patrick mcmanus 2016-09-26 14:55:23 UTC
I don't have a repro for you - you'll need to download firefox 52 or canary. Sorry if you don't want reports about your project in your tracker - that's the only way I can track reports for my project. I was trying to be helpful. Feel free to close if you're fine with tomcat not working with chrome or firefox - definitely your call I won't be offended.
Comment 3 Remy Maucherat 2016-09-26 15:01:44 UTC
Here is the right place, I don't see the point of the other two. And the details should be here.
Comment 4 Matt 2016-09-26 15:58:23 UTC
I created the bugzilla report at mozilla.org, not Patrick, because it appeared to me to be a regression in Firefox. I guess looking at who reported it was probably not an option. ;) I had no reason to believe it was a bug in Tomcat since it was working with all previous versions of Firefox and in released versions of other browsers. I tried rolling Tomcat back to previous versions of 8.5 and got the same behavior. If I hadn't reported it at mozilla.org we wouldn't have discovered the source of the issue, since you probably would have just responded with snark if I reported it here.
Comment 5 Remy Maucherat 2016-09-27 15:33:36 UTC
Tomcat will now support up to 64kB, it was previously harcoded to 16kB in a slightly hidden fashion. This has been fixed in the following branches: - 9.0.x for 9.0.0.M11 onwards - 8.5.x for 8.5.6 onwards
Comment 6 patrick mcmanus 2016-09-27 16:09:18 UTC
awesome. thank you. I'll update the firefox bug with the release info so anybody tripping over it will know what they need to update to. can I ask what happens if a client advertises >64KB? I'm assuming tomcat just uses 64 and ignores the rest but wanted to ask.
Comment 7 Matt 2016-09-27 17:18:28 UTC
Comment 8 Remy Maucherat 2016-09-28 07:27:21 UTC
(In reply to patrick mcmanus from comment #6) > can I ask what happens if a client advertises >64KB? I'm assuming tomcat > just uses 64 and ignores the rest but wanted to ask. 64*1024 is the new size limit.
Comment 9 patrick mcmanus 2016-09-28 12:25:36 UTC
(In reply to Remy Maucherat from comment #8) > (In reply to patrick mcmanus from comment #6) > > can I ask what happens if a client advertises >64KB? I'm assuming tomcat > > just uses 64 and ignores the rest but wanted to ask. > > 64*1024 is the new size limit. can I ask what happens if a client advertises >64KB? does the connection fail? Afterall the client cannot know what your limit is.