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

On 7/12/2011 9:49 p.m., Mark Nottingham wrote:
> On 03/12/2011, at 5:53 PM, Willy Tarreau wrote:
>
>> The issue I have with this is that for me, violating the spec simply implies
>> not doing a MUST or doing a MUST NOT. There are a huge number of such rules
>> in the spec, many of them irrelevant to most proxies. And by ignoring these
>> rules, the proxies will violate the spec by forwarding wrong contents. Your
>> example of the Date header is perfect. It's a general header with a MUST for
>> the format, still a number of proxies don't care about it and will not check
>> it. By forwarding a wrong one, they will violate the spec.
> This is a good point. I think we can address this by changing this in the sections on conformance (one per draft, IIRC):
>
>>     This document also uses ABNF to define valid protocol elements
>>     (Section 1.2).  In addition to the prose requirements placed upon
>>     them, Senders MUST NOT generate protocol elements that are invalid.
> to something like:
>
>>     This document also uses ABNF to define valid protocol elements
>>     (Section 1.2).  In addition to the prose requirements placed upon
>>     them, Senders MUST NOT generate protocol elements that are invalid,
>>     unless the element is out of their control (such as a header generated by
>>     an upstream sender), in which case they MAY attempt to correct
>>     the syntax before sending.
> Thoughts? We'd still have the option of making specific exceptions where we require generation to be conformant (e.g., when there are security implications).

The multi-part sentence seems a bit bulky. Maybe a separate sentence 
specifically aimed at middleware? "generate" is pretty clearly aimed at 
agents adding things to the headers.

Would it make sense to specify that proxies MUST (SHOULD? "ought to"?) 
fix headers which they pay attention to and identify as invalid?
That leaves a huge loophole that they can ignore a header entirely for 
both usage and relay purposes without being in violation. But if they 
are smart enough to make use of it and validate they become part of the 
interoperability correction mechanism for HTTP.

IMHO something stronger than MAY would be useful to encourage in-transit 
corrections toward validity. The process of erasing invalid headers 
pushes the valid formats more into view of those who dont read the specs.

AYJ

Received on Wednesday, 7 December 2011 10:41:45 UTC