On 6/23/05, jean-frederic clere <[EMAIL PROTECTED]> wrote:
> William A. Rowe, Jr. wrote:
> > ++1 To Joe's comments.
> >
> > Jeff's fix is technically right, but scares the nibbles out
> > of me. If, for example, an exploit is able to inject the
> > T-E on top of the legit C-L, I really suspect we should not
> > trust the origin server at all.
One important situation to fear is a buggy server or proxy+server that
we may not be able to talk to at all if we are extremely strict.
[As you implied w.r.t. Apache 1.3] The smuggling fear is really if we
allow keepalive on this connection to the origin server again. We
could be confused by making the wrong choice from {CL, TE} and
misunderstand the next response. We can set backend->close and
origin->keepalive to prevent that.
If we don't allow keepalive, then it is down to whether or not this
single request can be parsed correctly if our choice of {CL, TE} makes
sense.
> > For origin servers (as opposed to clients) make this choice
> > between ignore C-L, or fail, configurable?
try very hard to make a reasonable choice with no configuration :)
(speaking to the choir, of course)
> >
> > My observation is that there are far more varied clients in
> > the world than servers, each with unique faults. But the
> > RFC 2616 is clear...
> >
> > Messages MUST NOT include both a Content-Length header field and a
> > non-identity transfer-coding. If the message does include a non-
> > identity transfer-coding, the Content-Length MUST be ignored.
> >
> > When a Content-Length is given in a message where a message-body is
> > allowed, its field value MUST exactly match the number of OCTETs in
> > the message-body. HTTP/1.1 user agents MUST notify the user when an
> > invalid length is received and detected.
> >
> > ...and server authors can be expected to be less buggy than clients.
> > "Permissive in what we accept, strict in what we send" implies some
> > strictness in what we trust to pass on to the client.
We're removing the protocol breakage in what we pass on to the client.
At this point, we either send a valid response or it is if the server
dropped the connection before sending the full response.
(I hear what you're screaming. I think the minimal-intervention path
should be preferred if we can justify it.)
> > So +.5 to Jeff's patch, and let's discuss if the proxy response should
> > then be trusted at all with T-E and C-L, in httpd-2.x where we support
> > keepalives.
>
> Once the patch applied we lose the information that the request was
> "incorrect".
> That means we won't be able to choose in proxy between sending C-L (and
> dechunk)
> and T-E.
I don't follow here. How does the backend choice of {TE, CL} affect
what we send the client?
