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

[Mark Nottingham <[e-mail]>]

Sounds like it might need some grease...


> On 15 Oct 2020, at 2:21 pm, Willy Tarreau <[e-mail]> 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/