W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: clarify some MUST requirements in HTTPbis part 1 section 3.3

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 7 Dec 2011 16:30:06 -0800
Cc: Willy Tarreau <w@1wt.eu>, Alex Rousskov <rousskov@measurement-factory.com>, ietf-http-wg@w3.org
Message-Id: <CDED81A4-90FD-4EFD-B49E-1FDADFE5DE9F@gbiv.com>
To: Mark Nottingham <mnot@mnot.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT