- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 15 Oct 2020 14:30:02 +1100
- To: Willy Tarreau <w@1wt.eu>
- Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
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