Re: HTTP/1.1 to clients in v3.2

On 08/16/2010 01:52 PM, Henrik Nordström wrote:
> mån 2010-08-16 klockan 13:30 -0600 skrev Alex Rousskov:
>
>> Since Squid is a program and not a human being, we do need to hard-code
>> a single default. Clearly, there will be ACLs to change the behavior,
>> but if no options apply, we still need to do something.
>>
>> Yu have more-or-less said "no" to every option I listed :-). Correct me
>> if I am wrong, but I sense that option #1 (always send chunked request)
>> is the "least bad" default. I will try to implement that unless you stop me.
>
> I did not say no, just the complications each proposal involves..
>
> The correct per spec is to reject with 411 unless next hop is known to
> be 1.1.
>
> Alternatively dechunk if we have already received the full body (by
> waiting a little, not sending 100 Continue)

Should we try implement what you described then? In summary:

   - If the next hop is known to be 1.1, send a chunked request.
   - Otherwise, try to accumulate the full body, with a timeout.
     Send 411 if we timed out while accumulating.

At first, the accumulation will still happen on the client side, like
today. Eventually, the accumulation code can be moved to the server side.

Is this the right path forward?

Thank you,

Alex.

>> An interception client is arguably more likely to know the next hop
>> capabilities because it thinks it is talking directly to that hop.
>
> I would argue the opposite. It's less likely to make a correct decision
> as it do not expect the proxy to be there messing with things so it
> quite likely will take the response version of the proxy as an
> indication of the origin server capabilities not caring to look for Via
> etc..
>
>> Similarly, we are less likely to be blamed for screwing things up if we
>> just repeat what the intercepted client did.
>
> Until someone slaps us with the specifications.
>
> Regards
> Henrik
Received on Mon Aug 16 2010 - 20:08:32 MDT