On 6/23/05, jean-frederic clere <[EMAIL PROTECTED]> wrote: > 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?
This second patch is a bit confusing out of context because of the use by that function of r->headers_OUT for information we have READ from the origin server. It doesn't affect what we send to the next proxy as far as I can tell. The original patch could affect what we send to the next proxy.