- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 22 Nov 2013 22:11:13 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, 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>
On Fri, Nov 22, 2013 at 10:05:28AM -0800, Martin Thomson wrote:
> On 21 November 2013 19:14, Mark Nottingham <mnot@mnot.net> wrote:
> >> 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.
>
> Wasn't there some guidance that came out of the websockets work to
> this effect already? I believe that Connection:close was something
> that was found to be useful in both directions.
Yes I remember having discussed about this to great extents but I don't
remember the outcome.
> Sadly, the 101 can
> sometimes be interpreted as being informational by the intermediary,
> whereupon it has trouble identifying the final response.
Yes if the intermediary considers it as equivalent to 100 since the spec
suggests so (fallback to the x00 code of the same class). I'm not aware
of any doing that but surely they do exist. Well... just checked and
haproxy used to do this between versions 1.3.21 and 1.3.23 inclusive,
4 years ago. So it definitely does exist.
> Adding a
> server prologue that starts with 5xx GTFO\r\nConnection:close\r\n\r\n
> might help, but is that overkill?
I'm not totally convinced in fact. On the one hand, returning something
not acceptable by a parser might help it reject the message and close. On
the other hand, some parsers might consider this is an HTTP/0.9 response
and forward until the connection closes (which might be good or bad,
depending whether the request channel is still forwarding or not). Still,
I suspect that an unparsable response might be enough without being
overkill (eg: "HTTP2!\r\n").
Another possibility is to rely on "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
as suggested in RFC1945 to detect 0.9 vs later versions, and fail just
after with an error code and some non-parsable contents :
HTTP/2.0 500 \x00\r\n\x00\r\n\r\n
The most permissive ones would probably close on "2.0", "500" or the lack
of CRLF before \x00 or lack of CRLF. The most compliant ones will probably
abort on \x00 in the header name.
I thought that a valid HTTP response such as "HTTP/2.0" with an error code
and an invalid content-length might also have chances of being caught, but
looking at the old haproxy versions above, it will pass unmolested !
Regards,
Willy
Received on Friday, 22 November 2013 21:11:58 UTC