Jeff Trawick wrote:
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?
If we are acting as a proxy, what we send to the next proxy is changed by the
patch, isn't it?
