Closed Bug 1305321 Opened 4 years ago Closed 3 years ago

HTTPS connection fails to Tomcat 8.5 server

Categories

(Web Compatibility :: Desktop, defect)

Firefox 52
defect
Not set

Tracking

(firefox49 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52- fixed)

RESOLVED FIXED
Tracking Status
firefox49 --- unaffected
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 - fixed

People

(Reporter: mattcoz, Unassigned)

References

Details

(Keywords: regression)

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.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e3cff5e3ae3cc1b20d4861e7934e54c9e407a750&tochange=5194eeb6ca2d34b5fca72d2a78d6a9ec95a36763

Triggered by: Bug 1296280
Blocks: 1296280
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Flags: needinfo?(hurley)
Keywords: regression
Product: Firefox → Core
(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.
Whiteboard: [necko-aktive]
Whiteboard: [necko-aktive] → [necko-active]
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...
Flags: needinfo?(hurley)
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
Whiteboard: [necko-active]
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
Duplicate of this bug: 1307060
No need to track this based on Comment 9.
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.