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

[Willy Tarreau <[e-mail]>]

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