- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 7 Dec 2011 16:30:06 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Willy Tarreau <w@1wt.eu>, Alex Rousskov <rousskov@measurement-factory.com>, ietf-http-wg@w3.org
On Dec 7, 2011, at 3:13 PM, Mark Nottingham wrote: > On 08/12/2011, at 4:30 AM, Roy T. Fielding wrote: > […] >> A proxy is responsible for complying with all requirements on senders, >> clients, and proxies. That is how the entire protocol is written. >> While I understand that some folks may not want to do that, the answer >> is that their software is not compliant with HTTP. There is no need for >> further exceptions. >> >> There are many "proxies" that are not HTTP proxies. > > > So, how is a proxy that receives an invalid Date header supposed to handle it? Re-generate the Date? Does *any* implementation do this? > > Likewise for, say, a Cache-Control header where an extension directive doesn't meet the generic ABNF; what should a proxy do? Does any existing implementation actually do it? > > If no (or very little) software is compliant with HTTP, that begs the question of whether compliance with HTTP is defined well. Most people who have implemented a "proxy" have, in fact, implemented a broken tunnel, TCP forwarder, or gateway. Relaxing the HTTP requirements on proxies does not help them whatsoever. The requirements are there for actual proxy implementations that wish to be interoperable with the recipients of the messages they send. If a specific requirement is not necessary for interoperability, then it shouldn't be in the spec as a requirement! One of the major problems with 2616 is that a huge amount of prose of 2068 was elevated from description to requirement very late in the review cycle. If you find a broken requirement, then it should be fixed. In contrast, giving proxies a free pass does not help them -- it just fails to define the protocol. Let's not forget that almost all problems associated with extending HTTP and using pipelines in practice are due to broken intermediary implementations not adhering to one or more of the interoperability requirements of HTTP. ....Roy
Received on Thursday, 8 December 2011 00:30:29 UTC