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:09:24 -0500
Message-ID: <CACuKZqExeBDe42y=feEj2HPg0hxKXLr57A1WaLL6d1njDe-xmg@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>
Some small problems with the spec:


The meaning of 417 is vague. If a server isn't interested in the body
of a request with "Expect: 100-continue", SHOULD the server send 417?
I don't think so, there can be many reasons why the server isn't
interested in the body; it should send a specific response code
reflecting the real reason, e.g. 403.

Server's intent that the client does not send the body is already
expressed by not sending 100 before the final code; there's no value
in 417 repeating that intent.

Then 417 is only useful when the server cannot understand the expectation.

Requirements for HTTP/1.1 origin servers:
  ... (the server) MUST NOT perform the request method if it returns a
final status code (without a prior 100)

That's too harsh, isn't it? Though the server doesn't need to read the
request body, that doesn't mean the request cannot be served. Maybe
the request headers contains sufficient information, and the request
body is just a redundancy measure.

Zhong Yu
Received on Friday, 20 July 2012 19:09:51 UTC

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