- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 21 Nov 2013 10:46:25 +0100
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Michael Sweet <msweet@apple.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Thursday, 21 November 2013 09:47:11 UTC