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

Re: Getting to Consensus on 1xx Status Codes (#535)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 18 Jul 2014 15:44:13 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E7832115-9B66-44CD-B034-B60F814C277A@gbiv.com>
To: Michael Sweet <msweet@apple.com>
On Jul 18, 2014, at 12:20 PM, Michael Sweet wrote:

> Roy,
> 
> I think the issue *I* have with more 1xx status codes is that, thanks to the precedent set by 101, the recipient can't just ignore a 1xx status code it doesn't understand and wait for another response to come along.

An HTTP/1.1 recipient cannot ignore 101.  An Upgrade header isn't
going to pass though a proxy that doesn't understand 101, unless
the proxy doesn't implement Connection and deliberately violates the
standard by forwarding as HTTP/1.1.  In that case, it will be screwed by
persistent connections long before it ever sees an Upgrade.

The rules for handling 1xx extensions are defined by 100, not by 101.
101 required a change to the HTTP version to be introduced.  The same
would be true if we were to require specific handling of a future
status code, regardless of the 1xx-5xx class.  The obligation is on
the server that generates the status to verify that it is sending it
to a client capable of following the requirements.

IOW, if a client receives a 1xx status code that it doesn't understand,
then it can ignore it if and only if it didn't claim to understand that
status when it made the request.  If the client lies about its capabilities,
then things will get messy no matter what protocol is used.

> And there is no guarantee that a particular status code is transmitted end-to-end - 101 is certainly a per-hop mechanism, and in my experience 100 is commonly dropped by proxies.

101 is designed to be hop-by-hop.  100 and 102 are not.  What does that say
about 1xx codes in general?  Nothing.  Just like the other status codes.

A proxy that claims to be HTTP/1.1 and drops *any* status code when
forwarding to an HTTP/1.1 (or higher) client is not conforming to the
HTTP standard unless it is doing so explicitly to support a configured
workaround due to the client lying about its own version capabilities.

A non-conforming proxy will occasionally fail to interoperate with
conforming user agents and origin servers.  There is nothing we can do
about that other than to remove such non-conforming software.
Things break, with or without guarantees.

Our goal is to allow conforming implementations to do useful things,
which they do just fine in spite of the occasional glitch. Browsers
may well be concerned if 5% of networks have a broken proxy, since
it is rare for their customers to have the power to fix that proxy.
My customers usually have control over their own network.  The fact
that we can all use the same protocol to get things done is one of
the benefits of HTTP.

....Roy
Received on Friday, 18 July 2014 22:44:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC