W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Optional Connection fields in 1xx messages and Upgrade requests

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 14 Oct 2020 19:52:37 -0400
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <b8d3cd2c-4f1a-ce4a-b9c5-f990c07ed8bd@measurement-factory.com>
On 10/14/20 5:33 PM, Amos Jeffries wrote at
https://github.com/squid-cache/squid/pull/732#issuecomment-708672207:

> Your response answers my question about testing. That clearly indicates
> a buggy Voice service. If you can please document your tests and report
> to the relevant Google dev if you can find them and/or the HTTPbis WG so
> the spec authors can be aware of this case for the latest spec update.

I am not sure adjusting HTTP specs can help in this case, but I am
documenting the problem here per Amos request.


After adding support for HTTP Upgrade mechanism to Squid, we have
encountered several services that fail the Upgrade "handshake" (and,
hence, do not switch to a new protocol) only because Squid sent an
"extra" Connection header field or field value. There are two known cases:


* 101 (Switching Protocols) with "Connection: upgrade, keep-alive"

Client applications using websocket_client[1] library refused to upgrade
upon receiving a "Connection: upgrade, keep-alive" header field in an
HTTP/1.1 101 (Switching Protocols) response. The (unnecessary)
keep-alive addition was the culprit. I do not know whether sending two
Connection header fields would have worked better.

[1] https://pypi.org/project/websocket_client/


* HTTP/1.1 GET request with "Connection: keep-alive"

A Google Voice service[2] rejected Upgrade requests with a 400 (Bad
Request) response if the _last_ Connection header field did not have an
"upgrade" value. The current behavior has changed to resetting the TCP
connection.

[2] https://web.voice.telephony.goog/websocket


Both cases have one thing in common -- they follow HTTP RFC examples to
the letter but do not handle "extra" Connection headers in the
Upgrade-related messages (that those examples do not and should not have).

It may be a good idea to emphasize that both the upgrade-seeking request
and a 101 response may include additional Connection headers, especially
Connection: keep-alive. The agent participating in the upgrade MUST
support enough of HTTP to not be confused by additional Connection
headers (at least). The HTTP Upgrade mechanism is an HTTP mechanism.


HTH,

Alex.
Received on Wednesday, 14 October 2020 23:52:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 14 October 2020 23:52:55 UTC