W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Fri, 20 Jul 2012 14:35:00 -0500
Message-ID: <CACuKZqHw1jncasrOLncGHSm1JD7y5J3OoGNY39j5_bqgDnHmaQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Roberto Peon <grmocg@gmail.com>, James M Snell <jasnell@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, Osama Mazahir <OSAMAM@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
What are the reasons for such great efforts to keep connection alive
when a 100-continue fails? Is it really a big deal to drop connections
once in a while?

If the client receives a final code, not 100:

1. before sending the request body - it should not send the body.
2. during sending the request body - it should immediately stop
sending the body any further.

In both cases, the client should close the connection after the final
response is read. It should not fake a graceful end-of-body with a
0-chunk, because that is lying - to the observers, it seems that the
client successfully sends a complete body, and the body content is

3. after sending the request body - no problem here, connection remains good.

If the server does not respond with a 100, it should close the
connection after the final response is written. There is no point to
attempt to read till the end of request body - that will fail anyway
in most cases. If the client is mischievous and continues to send the
body, server will be on a fool's errand to consume the useless bytes.
That'll waste more resources than simply drop the connection.

Zhong Yu
Received on Friday, 20 July 2012 19:35:31 UTC

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