Created attachment 379352 [details]
unparsed status line passed to WebSocketChannel::fail(m_handshake->failureReason()
websocket servers that respond with truncated "h2 style" status lines like 'HTTP/1.1 101\r\n' are rejected by Safari:
$ curl -si 'https://web.voice.telephony.goog/websocket' -H 'Host: web.voice.telephony.goog' -H 'Upgrade: websocket' -H 'Connection: Upgrade' -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" -H 'Origin: https://voice.google.com' -H 'Sec-WebSocket-Protocol: sip' -H 'Sec-WebSocket-Version: 13' | head -n1 | hexdump -c
0000000 H T T P / 1 . 1 1 0 1 \r \n
I've cross reported this to the Google Voice forum:
That endpoint is for a product that specifically detects-and-degrades on Safari, but maybe that is not such an unusual kind of response line.
Chromium and Firefox use their canonical browsing parsers to validate the handshake's response, and theirs do not
seem to require a status text:
whereas webkit requires the status-code sent between two spaces:
Created attachment 379353 [details]
inspector preview shows no parsed response
autobahn.py's WS testsuite* seems to agree with Chrome & FF handshake impls, but not webkit's:
# Response Line
sl = self.http_status_line.split()
if len(sl) < 2:
return self.failHandshake("Bad HTTP response status line '%s'" % self.http_status_line)
In : len("HTTP/1.1 101".split())
Its tyranny of the majority (of UAs), including Safari, if its using NSURLSession & I'm following it accurately:
httpReceiveResponse is just checking it got all the bytes it can get
nextActionForHeaders() calls CFHTTPMessageGetResponseStatusCode(CFMessageRef headers)...
looks for the .flags[status] that *_extractResponseStatusLine got when initializing the CFHTTPMessage (after _parseHeadersFromData was fired on the last append of message's bytes)
*_extractResponseStatusLine(...) seems to parse for just the code numbers
Very hard to follow!
But this is borne out when trying to browse this server in Safari.
it's inspector says:
"Failed to load resource: the server responded with a status of 400 () -- https://web.voice.telephony.goog/favicon.ico"
showing CFNetwork does tolerate the truncated status line.
I suppose there's already a task open to convert webcore:websockets to NSURLSession or CFURLConnection?