At 05:45 AM 6/23/2005, 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.
>
>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
