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: Mark Nottingham <mnot@mnot.net>
Date: Thu, 8 Dec 2011 11:34:04 +1100
Cc: Willy Tarreau <w@1wt.eu>, Alex Rousskov <rousskov@measurement-factory.com>, ietf-http-wg@w3.org
Message-Id: <519042F3-D1A7-4536-8857-1EB4285EF601@mnot.net>
To: Roy T. Fielding <fielding@gbiv.com>

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
Received on Thursday, 8 December 2011 00:34:43 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC