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

On 08/12/2011, at 11:30 AM, Roy T. Fielding wrote:
>> 
>> 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.

Oh, absolutely. I don't have much interest in making these devices conformant to HTTP by changing the spec.

> 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!

Right. See discussion above; this is what we're trying to clarify.

> 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.

Ack; the evidence of this is everywhere, and it's quite annoying.

> 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.


Right. So, back to the questions above -- what is a HTTP proxy supposed to do in these situations? Should this specific requirement be relaxed?

--
Mark Nottingham
http://www.mnot.net/