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

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

Received on Tuesday, 14 September 2010 20:35:53 UTC