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

On 12/07/2011 01:49 AM, Mark Nottingham wrote:
> On 03/12/2011, at 5:53 PM, Willy Tarreau wrote:
> 
>> 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.


The above wording is an improvement over RFC 2616 but it raises the same
"generate vs. forward" doubts. Many proxy developers claim that their
proxies do not generate end-to-end headers and, hence, ignore the above
MUST NOT. The specs do not make it clear whether they are right. We must
polish this.


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


I like the intent, but the text is still problematic in several areas:

* "generate" is probably undefined and may mean different things to
different developers

* "out of control" is probably undefined and will mean different things
to different developers

* "correct the syntax" permission implies that other corrections are not
allowed, which contradicts best practices in some cases.


I am afraid we have to explicitly acknowledge that forwarding of
protocol elements exists and that forwarding comes with its own small
set of rules. Here is a draft:

    We use the term "generate" to describe an agent action of creating
    a protocol element. We use the term "forward" to describe the
    intermediary action of sending a protocol element received from
    another agent. By definition, a forwarded element is sent exactly
    as received except for permitted whitespace changes. Any other sent
    element is considered generated by the agent sending it.

    This document uses ABNF and prose requirements to define valid
    protocol elements (Section 1.2). An agent MUST NOT generate invalid
    protocol elements. Unless explicitly required to do otherwise for a
    specific element, an intermediary MAY forward invalid protocol
    elements. If an intermediary receives an invalid protocol element,
    it MAY generate and send an equivalent valid protocol element,
    taking the responsibility for all associated risks.


The above needs more work, but I think it resolves the major problem of
trying to have the same set of rules for element generation and
forwarding, which are fundamentally different actions. What do you think?


Thank you,

Alex.

Received on Wednesday, 7 December 2011 17:03:52 UTC