Closed Bug 1305321 Opened 4 years ago Closed 3 years ago
HTTPS connection fails to Tomcat 8
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20160924030427 Steps to reproduce: The following website is running on a Tomcat 8.5 server. It is a copy of our live website that is running on a Tomcat 7 server, which is working perfectly. https://test.arclearn.com Actual results: 49.0: website loads 50.0b1: website loads 51.0a2: website loads 52.0a1: nothing happens There are no errors in the console, the network monitor shows the initial connection but no response, and there is nothing in any of my server logs to show that it ever gets to the server. The HTTP URL works, it gets to the server which then responds with a redirect to HTTPS, which then does nothing. Expected results: The website should have loaded.
I've had confirmation of this behavior from multiple other people.
(FYI, Setting network.http.spdy.default-hpack-buffer = 4096 and restart seems to fix the problem)
I can confirm that changing that setting fixes the problem for me. It works at 4k, 8k, and 16k. It fails at 32k and 64k.
how does it do with chrome canary? (which iirc has the same change you see in firefox 52)
I just tried the URL in comment 0 in canary, and got a "This site can't be reached" error, same kind of behavior as we see with nightly (though we don't have an error page show up in nightly). Sounds like Tomcat has issues with a 64k HPACK table...
I'll note this in the chrome bug tracker and mark this bug as evang - that's a server side bug https://bugs.chromium.org/p/chromium/issues/detail?id=642784
Component: Networking: HTTP → Desktop
Product: Core → Tech Evangelism
Version: 52 Branch → Firefox 52
fast reaction from tomcat team! from https://bz.apache.org/bugzilla/show_bug.cgi?id=60173#c5 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
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
updating 52 status flag (not sure fixed is the right one, since this wasn't our bug to begin with, but it'll at least get this off the regression list)
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.