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: Alex Rousskov <rousskov@measurement-factory.com>
Date: Thu, 08 Dec 2011 08:25:25 -0700
Message-ID: <4EE0D6E5.8040105@measurement-factory.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>, ietf-http-wg@w3.org
On 12/07/2011 05:43 PM, Roy T. Fielding wrote:
> On Dec 7, 2011, at 4:34 PM, Mark Nottingham wrote:
>> Right. So, back to the questions above -- what is a HTTP proxy supposed to do in these situations? Should this specific requirement be relaxed?
> 
> Yes, that's what I said earlier -- it is a bug to say that the field-value
> MUST be sent in a specific form when senders are not expected to rewrite
> the field-value, and might actually be forbidden from doing so by other
> requirements.  What it is supposed to say is that newly generated Date
> field-values MUST be of the standard form.

I think it is likely that there is consensus that proxies may forward
invalid protocol elements that they did not generate and that are not
related to "framing" and similar "core" issues.

Where we may not agree is how to codify that in the protocol. We have
two basic options:

1. Avoid any global exceptions for proxies. Make sure every sending
requirement is carefully formulated so that proxies are excluded if they
ought to be excluded. For example, a "Date-generators MUST generate Date
in standard form" rule would exclude proxies unless they add Date (when
such addition is required).

2. Provide a global exception for proxies. Make sure every "core"
sending requirement is carefully formulated to preserve "framing" and
such. For example, a "Agents MUST send Date in standard form" rule works
fine because the "global proxy exception" will provide a necessary
exception for proxies.

As far as compliant HTTPbis implementations are concerned, both
approaches will result in exactly the same outcome. Niether approach
grants proxies more freedoms!


IMO, the key difference between the two approaches actually lies outside
RFC 2616 and HTTPbis. We are not going to rewrite all existing
HTTP-based specs and we are unlikely to be very good at controlling all
new ones. If not explicitly codified, the understanding of this issue
will die and the problems will resurface. That is why I think it is
better to provide an explicit global exception for proxies.

Please note that both approaches will require introduction of new
normative vocabulary. AFAICT, we currently do not have any normative
language that clearly distinguishes "generation" from "forwarding" in
the context of "sending". That has to be fixed regardless of the
approach. Otherwise, proxy developers will continue to misinterpret
"send" and "sender" rules.

I have proposed specific wording for the "global exception for proxies"
approach. If there is consensus that the first approach is the way to
go, I would be happy to try to reshape that proposal to just introduce
the necessary generation/forwarding vocabulary.


Thank you,

Alex.
Received on Thursday, 8 December 2011 15:27:20 GMT

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