Re: Issues addressed in the -10 and -11 drafts

If lots of implementations are breaking in obvious ways because of duplicate headers, it will encourage those broken intermediaries to fix themselves.

However, we should discuss how UAs will display such errors to users. 

Currently, the language implies that the content is displayed to the user by the UA, as well as (SHOULD) an error message. Will that SHOULD get implemented? 

If not, intermediaries will get bug reports because a site sending two C-L headers will work with browsers, but won't work when an intermediary is interposed -- incenting them not to implement.

A few possible fixes:
  0) status quo -- UA vendors are happy to display an error to the user, because this type of error is so rare. (UA vendors?)
  1) UA required NOT to display / make available content with multiple C-L headers, giving parity with intermediaries (if they implement).
  2) Change requirement to focus on not using any more messages after this one in the connection, as they're tainted. 

Thoughts?


On 15/09/2010, at 6:35 AM, Willy Tarreau wrote:

> On Tue, Sep 14, 2010 at 12:02:26PM +0200, Julian Reschke wrote:
>> On 14.09.2010 07:50, Willy Tarreau wrote:
>>> ...
>>>> I think there are two concerns here:
>>>>  1) making the spec more complex
>>>>  2) making code implementing the spec more complex
>>>> 
>>>> Is it going to cause your implementation problems to refuse messages 
>>>> with two matching content-length headers?
>>> 
>>> No, it's even easier, I can remove a test in the code ! But I
>>> suspect that I'll have to relax the check again in a few months
>>> to a few years because of the effect mentionned above. Maybe we
>>> could add a single sentence at the end of point 3 of 3.3 :
>>> 
>>> "An implementation MAY accept exact duplicates of valid Content-Length
>>>  header fields as a single one, though this practice is discouraged".
>> 
>> We currently have:
>> 
>> "If a message is received without Transfer-Encoding and with either 
>> multiple Content-Length header fields or a single Content-Length header 
>> field with an invalid value, then the message framing is invalid and 
>> MUST be treated as an error to prevent request or response smuggling."
>> 
>> We can't have a MAY relax a MUST; that makes it a "SHOULD".
>> 
>> We could relax this edge case from MUST to SHOULD, but it would 
>> complicate the spec a lot, and I'm not convinced it's really needed.
> 
> Indeed, I see your point. Alternatively, couldn't we keep the must
> and slightly adjust the text :
> 
> "If a message is received without Transfer-Encoding and with either 
> multiple differing Content-Length header fields or any Content-Length
> header field with an invalid value, then the message framing is invalid
> and MUST be treated as an error to prevent request or response smuggling."
> 
>> It would be great to have more data on this.
> 
> I agree, though that's not easy to catch on purpose :-(
> 
> I have seen a type of component which tend to create duplicate headers,
> though I've not observed that with the content-length particularly. The
> type of component is in the class of all the application-level proxies
> developped by some companies to perform various checks on application
> contents that are to be forwarded inside or outside, and that rely on
> a combination of a web server API + an HTTP client library. Eg: FCGI +
> libcurl or anything like this. The issue is that the HTTP client will
> automatically set some headers (eg: content-length when posting data)
> while the application code will blindly copy headers provided by the
> web server's API. It's the same practice that sometimes leads to duplicate
> cookies or other such headers. But once again, it's not easy to find
> such crappy components (that generally remain on private networks) and
> to audit them :-/
> 
> Regards,
> Willy
> 


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

Received on Wednesday, 15 September 2010 03:44:50 UTC