> > > However, there's one more problem - squid complains (and returns a 411
> > > error) if methods which aren't meant to have a Content-Length header
> > > have one. For example, a get request should NOT have a content-length.
> > > Right now, we send content-length whenever we can, though it'll often
be
> > > the default value (I haven't checked, but I imagine this is 0). So, we
> > > need to suppress this on methods that don't need it.
> >
> > Where did you read that ?
> > As long as the content length value is accurate (ie, equals 0 when doing
a
> > GET), I fail to see why it would be forbidden (and couldn't find that in
the
> > HTTP/1.1 spec).
> > 411 means Length required, so it should be returned in the exact
opposite
> > case.
>
> I inferred it from a) various squid mailing list posts, b) the fact that
> squid gave a 411 when the client sent this content-length, and c) the
> fact that, when I supressed the content-length header for this case,
> squid started working.
>
> I'm not sure WHY squid requires this, and it might (though this isn't
> anything new - and squid is VERY widely used, so I suspect it's not a
> bug in squid) be a squid problem, but this fix does work.
>
> I would guess (but I haven't read the entirety of the HTTP rfcs
> sufficiently recently to remember) that when there isn't a body,
> content-length is not meant to be set. I'll check on this when I have
> time.
Sure, here, fixing that is a no brainer (it also will save a few bytes in
the request). However, in more complex cases, it's definitely conformance to
the standard which matters.
If anyone could send a pointer to the chapter in the HTTP/1.1 spec which
says that Content-Length: 0 is not allowed in a GET method, I would be
interested.
Remy
