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
