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

On 12/02/2011 03:06 PM, Willy Tarreau wrote:
> On Fri, Dec 02, 2011 at 02:50:13PM -0700, Alex Rousskov wrote:
>> On 12/02/2011 02:11 PM, Willy Tarreau wrote:
>>
>>> Maybe something like this would make things clearer for
>>> proxy authors (with a better wording) :
>>>
>>>   When a proxy faces a malformed header, it must either reject the message
>>>   or fix the header before forwarding it. This applies to all headers the
>>>   proxy cares about for its processing, and in any case to Connection,
>>>   Content-Length, Host and Transfer-Encoding.
>>
>> Since the concept of "caring about the header" is not (and cannot be)
>> defined and "fixing the header" essentially means emitting a header that
>> complies with the specs, I believe the above is pretty much equivalent to:
>>
>>   In the absence of requirements specific to proxies, when forwarding
>>   an upstream message, an HTTP proxy MUST comply with requirements
>>   for HTTP clients. Consequently, if the upstream message is
>>   malformed, a proxy MUST NOT forward it "as is".
> 
> This is still as much ambiguous as what it currently is IMHO, because
> everyone will have a good reason to consider that some fixing is not
> under his responsibility.


The existence of good reasons to violate a MUST does not make that MUST
ambiguous. However, it does prove that the MUST itself is wrong and
should not be included in HTTPbis.


>> If we restrict ourselves to Content-Length handling, the above becomes:
>>
>>   When forwarding an upstream message with an invalid Content-Length
>>   header, a proxy MUST NOT send a message with an invalid
>>   Content-Length header to the next hop.
>>
>> followed by the current HTTPbis rules about appropriate reactions to
>> some specific kinds of malformed Content-Length headers.
> 
> I like this one much better, it sets the focus on a clear action even
> if it implies additional specific code in products.

Glad we have converged on something usable that we both can agree on! I
suspect the above wording can be improved, but it does resolve the
current ambiguity.


Thank you,

Alex.

Received on Friday, 2 December 2011 23:31:57 UTC