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

On Dec 7, 2011, at 10:52 AM, Alex Rousskov wrote:

> On 12/07/2011 10: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.
> Does the above imply that all compliant proxies must _validate_ all
> forwarded headers defined by RFC 2616, to make sure those headers do not
> violate any of the 600+ MUSTs?

In some respects, yes, such as for framing and folding.  In cases where
the proxy is not supposed to muck with the header field, the requirements
should be more tightly scoped.

> If this is how the protocol has to be interpreted, we must clarify that
> in HTTPbis because (without an explicit confirmation) many folks would
> continue to use a less demanding interpretation. We should then also
> explain what a proxy should do if a to-be-forwarded header field fails
> validation but is not needed for correct proxy operation (from UA and
> origin server points of view)?

Why do we need to clarify that in general?  We should just fix the bugs.

> Please consider the following specific example. A proxy receives an
> otherwise valid message with a Date header that violates the following MUST:
>  The [Date] field value MUST be sent in rfc1123-date format.

That's a bug.  For one thing, it is a poorly phrased requirement
because it doesn't target the responsible party (in this case, the
program that generates the field-value).  For another, there is
(or was) some other requirement somewhere that intermediaries must
not modify so-called end-to-end metadata used for caching or that
might appear in digest hashes.

> When forwarding the message, the proxy has a few choices:
>  0) Send the Date header field as it was received.
>  1) Do not send any Date header field.
>  2) Create and send a new Date header.
>  3) Reject the entire received message.
> What should a compliant proxy do?
> And Date is just one example. There are many other complex end-to-end
> headers that a given proxy does not need to validate to function
> correctly (from UA and origin server points of view) and that are
> difficult or even impossible to "fix" without creating more problems.

I don't agree -- we have been fixing this type of bug all throughout
this process.


Received on Wednesday, 7 December 2011 20:47:09 UTC