- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 18 Jul 2014 15:44:13 -0700
- To: Michael Sweet <msweet@apple.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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