Re: HTTP/1.1 to clients in v3.2

mån 2010-08-16 klockan 14:08 -0600 skrev Alex Rousskov:

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

Yes.

Suggested implementaiton order:

1. Forward of chunked requests.
2. Next hop version cache, rejecting with 411 if next hop not known to
be 1.1
3. Delay 411 response condition a bit, buffering the request hoping to
be able to dechunk instead. Respond with 411 on timeout or buffer full.
4. tuning knob to selectively assume next hop is 1.1 if unknown,
enabling out of band knowledge of 1.1 capability via configuration. This
should also include tuning for selectively disabling chunked forwarding
enabling ban of broken nex-hops.
5. Option to add "Expect: 100-continue" on forwarded chunked requests
when forced 1.1, with it's requirements on delaying forwarding and
retrying without expectation if seeing a 417 in response or returning
411 if retrying is not possible at time of 417.

Note that when Expect: 100-continue is used by the client and complete
path is 1.1 then 3 should not really happen due to the client delaying
it's transmission for some considerable amount of time. Here we SHOULD
instead respond with 411 immediately to follow the 100 Continue expected
flow model, enabling client fallback to a much shorter delay.

In paralell to this it's also needed to deal with 1xx responses in an
reasonable manner, especially 100 Continue. Without these it's hard to
get the expected flow of events running.

Regards
Henrik
Received on Mon Aug 16 2010 - 21:31:31 MDT