Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050623083902.09e2f700@pop3.rowe-clan.net>
Date: Thu, 23 Jun 2005 08:43:55 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: 2.1.5 available for testing
In-Reply-To: <cc67648e05062303456124707b@mail.gmail.com>
References: <6.2.1.2.2.20050622145657.06df4eb0@pop3.rowe-clan.net>
 <20050622211223.GA4142@redhat.com>
 <42B9D66F.8020704@force-elite.com>
 <cc67648e0506221640630ff644@mail.gmail.com>
 <6.2.1.2.2.20050622220324.0cc106c0@pop3.rowe-clan.net>
 <42BA65FC.8070004@fujitsu-siemens.com>
 <cc67648e05062303456124707b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 05:45 AM 6/23/2005, Jeff Trawick wrote:
>On 6/23/05, jean-frederic clere <jfrederic.clere@fujitsu-siemens.com> 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.
>
>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.

So close the proxy connection if C-L and T-E are returned from the
origin server?  That would upgrade my +.5 to +1 - I totally agree.

>> > 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)

Yup - that was my concern too.

>> 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?

I really didn't understand that either.  The RFC really doesn't offer
any choice of how to interpret T-E and C-L (it states, ignore (drop)
the C-L header.  And we will pass the response to the client however
we agreed.

Bill