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

#1: Upgrade proposals [was: Call for Proposals re: #314]

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 22 Nov 2013 14:14:05 +1100
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Michael Sweet <msweet@apple.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D1823D68-B776-4F43-9CCA-688F11D8D3A3@mnot.net>
To: Willy Tarreau <w@1wt.eu>
How about changing the Subject: on this thread?


On 21/11/2013, at 8:46 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Nov 21, 2013 at 11:34:01AM +0200, Ilari Liusvaara wrote:
>>>> - 101 response is given, followed by HTTP/1.1 4xx/5xx error.
>>> Yes when the client pushes data to the server, believing the channel
>>> is clean. Generally a "400 bad request" or a "408 request timeout"
>>> can happen if the middlebox waits for a second valid request. This
>>> is the reason why in WS I preferred that we put "connection:close"
>>> in the exchanges (to incite middleboxes to close when non-compliant),
>>> but since I failed to make up that specific case again, I could not
>>> defend it anymore :-)
>> The process I considered to cause this was more like:
>> The middlebox passes the upgrade but doesn't process it (also passing
>> the 101). Thinks that the connection is still HTTP/1.1. Then the client
>> sends connnection magic, which of course causes things blows up...
> We're in sync. But if the 101 response contained "connection: close",
> the middlebox would most often propagate the close to the client and
> refrain from reading anything else. It's not rocket science though.
> Willy

Mark Nottingham   http://www.mnot.net/
Received on Friday, 22 November 2013 03:14:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC