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

Re: Optional Connection fields in 1xx messages and Upgrade requests

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 15 Oct 2020 14:30:02 +1100
Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
Message-Id: <F6E89B2D-E18F-43FF-9F1E-1E57B311EFD0@mnot.net>
To: Willy Tarreau <w@1wt.eu>
Sounds like it might need some grease...

> On 15 Oct 2020, at 2:21 pm, Willy Tarreau <w@1wt.eu> wrote:
> Hi Alex,
> On Wed, Oct 14, 2020 at 07:52:37PM -0400, Alex Rousskov wrote:
>> 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.
> Sadly I'm not surprised. That reminds me the (painful) period of the
> websocket design that some on this list certainly remember as well. There
> was a strong demand from some implementers to only use byte matching on
> the wire instead of parsing HTTP messages, presumably because HTTP was
> considered as the annoying protocol to switch away from, and I can easily
> imagine that initial code parts written this way have not much evolved.
> For having seen some HTTP code deployed in small IoT devices with just
> a few tens of kB of RAM and essentially relying on strstr() to spot
> header+value couples, I would suggest that each time we're dealing with
> protocol variations targetting these use cases, we must be very careful
> about how our messages are consumed. It's not necessarily easy nor even
> possible most of the time, but this needs to be anticipated to ease
> location of the problem at least.
> Cheers,
> Willy

Mark Nottingham   https://www.mnot.net/
Received on Thursday, 15 October 2020 03:30:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 15 October 2020 03:30:27 UTC