Re: [#95] Multiple Content-Lengths

On 09.03.2011 23:32, Roy T. Fielding wrote:
> On Mar 9, 2011, at 2:21 PM, Julian Reschke wrote:
>
>> On 09.03.2011 19:04, Mark Nottingham wrote:
>>> I've scheduled this for -13.
>>>
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/95#comment:20>
>>>
>>>
>>> On 20/02/2011, at 11:12 PM, Mark Nottingham wrote:
>>>
>>>> So, I propose:
>>>>
>>>> * adding text that allows duplicates explicitly, and
>>>>
>>>> * upgrading the SHOULD to a MUST in this requirement:
>>>>
>>>>    If this is a response message received by a user-agent, it SHOULD be treated
>>>>    as an error by discarding the message and closing the connection.
>>
>> ...clarifying: you say "adding text that allows duplicates explicitly"... that could be read to REQUIRE recipients to accept those duplicates -- are we really going to declare recipients that do not do that to be non-compliant?
>
> We need to require that they process received duplicates in the
> same way as all other recipients in order to avoid response
> smuggling.

I can think of three ways for recipients to handle these:

a) fail to parse C-L, and treat the message as invalid (closing the 
connection because of broken framing)

b) accept the duplicate value, and use the C-L as if it wasn't repeated

c) fail to parse C-L, and just treat the C-L header field as invalid, 
but continue processing by reading until the end of connection

Smuggling could only happen if some recipients did c), right? Those that 
do this IMHO are already non-compliant, so I'm not sure how mandating b) 
helps...

>> If we do, we *probably* need to adjust the header field ABNF (because "x, x" doesn't parse), which I'd rather do not...
>
> No, we still require that duplicates not be sent.  The ABNF
> only defines valid messages.  This new requirement is for
> exception handling in the case of an invalid received message.

Ack.

Best regards, Julian

Received on Wednesday, 9 March 2011 22:45:05 UTC