Re: [#95] Multiple Content-Lengths

Roy, Julian and I discussed this, and agreed that (a) and (b) are both valid. So, we propose this patch which will show up in -14:

  http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1214

... which should let us close #95. Any thoughts / objections?

Cheers,


On 09/03/2011, at 11:44 PM, Julian Reschke wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 27 March 2011 14:14:28 UTC