httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 2.1.5 available for testing
Date Fri, 08 Jul 2005 04:49:06 GMT
One more thought on this thread; wouldn't it be nice to
communicate to mod_cache not to trust this flaky response
or request TE+CL combination?  Unsetting the keep alive on
both the proxy and client adds some degree of saftey, but
marking this non-cachable would eliminate any likely hood
of cache poisoning.

I don't have the code, perhaps someone can point out an easy
answer for 2.0/2.1 or offer a patch to mod_cache to make that
toggleable.  In 1.3, this patch is trivial.

Just a thought,


At 05:45 AM 6/23/2005, Jeff Trawick wrote:
>On 6/23/05, jean-frederic clere <> 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
>> > 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?

View raw message