1546417 - Websocket Handshake Expecting Case-Sensitive Headers

Status: RESOLVED DUPLICATE of bug 1541339

(Core :: Networking: WebSockets, defect)

Description

[Dave Hawkins]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Use webapp to create a websocket.

Actual results:

Fails to create connection with the following console error:

Firefox can't establish a connection to the server at wss:<my server url>.

Expected results:

Create a websocket connection

Comment 1

[Dave Hawkins]

This was working in latest until fairly recently, probably March 2019. It stopped working at some point before 12th April 2019. It works in 60.3.0 esr.

This seems to be particular to the non-public server I'm trying to connect to, as https://www.websocket.org/echo.html seems to work fine. Normally I'd assume this was a problem with our server, but there seem to be some differences in the response headers displayed in network monitoring for the different versions of Firefox:

In earlier versions the displayed response includes the following headers:

Connection: upgrade
sec-websocket-accept: <Nonce>
sec-websocket-extensions: permessage-deflate
upgrade: websocket

In the broken version these are absent. Chrome, where this works, shows these headers.

For www.websocket.org, these headers are displayed, but they have different capitalisation:

Connection: Upgrade
Sec-WebSocket-Accept: <Nonce>
Upgrade: websocket

So I'm suspicious that a case-sensitive comparison is being done and the response headers are being incorrectly discarded somehow.

www.websocket.org also has a bunch of Access-Control-Allow-Headers in its response. However Access-Control-Request-Headers isn't being used.

Comment 2

[Kershaw Chang [:kershaw]]

Hi Dave,

It seems you can easily reproduce this with your own server. Could you try to use mozregression [1] to find out the root cause?
I've visited https://www.websocket.org/echo.html with firefox esr 60.6 and the capitalisation of response headers are the same as the firefox nightly, so I think capitalisation might not be the problem.

[1] https://mozilla.github.io/mozregression/

Comment 3

[Dave Hawkins]

I think you've misunderstood my comment about capitalisation. The non-public server is providing headers with all lower-case. www.websocket.org is using InitCap. When looking at the network monitor in Firefox 60, all the response headers are shown as expected and the websocket is created. In Firefox 67.0b12 the response for www.websocket.org is shown as expected and the websocket is created, but the response from the non-public server does not show the headers and the websocket is not created. That is, when a server response uses lower-case headers, these no longer seem to be recognised by Firefox.

However I've realised that the Cookie header is missing from the request and I think this is probably the cause of the problem. If I attempt to resend the request through the network monitor, I see that it's actually getting redirected to a login page so the headers really are missing from the response. The network monitor reporting could be a bit more helpful here. In normal operation the response body is just blank in this case, it's only when I resend that I start to see other requests.

After some discussion with the developers of the problematic server, this looks like it's probably a duplicate of:

https://bugzilla.mozilla.org/show_bug.cgi?id=1541339

That has a test case that reproduces for me.

Can we get the priority of that bug upped as this seems to be a fairly serious regression. I suspect it's also quite difficult to workaround.

Finally, as an aside, I couldn't get mozregression to work. I get the following error when I try to run it:

Traceback (most recent call last):
File "/usr/bin/mozregression", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3007, in <module>
working_set.require(requires)
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 728, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 631, in resolve
requirements.extend(dist.requires(req.extras)[::-1])
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2489, in requires
dm = self._dep_map
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2700, in _dep_map
self.__dep_map = self._compute_dependencies()
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2724, in _compute_dependencies
parsed = next(parse_requirements(distvers))
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 30, in <lambda>
next = lambda o: o.next()
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2839, in parse_requirements
line, p, specs = scan_list(VERSION,LINE_END,line,p,(1,2),"version spec")
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2817, in scan_list
"Expected ',' or end-of-list in",line,"at",line[p:]
ValueError: ("Expected ',' or end-of-list in", 'mozdevice >=1.', 'at', '')

However I don't have time to check whether that's an environmental issue on my side, so don't have time to log a reproducible test case.