At 06:34 AM 7/15/2005, Roy T. Fielding wrote:
>>All of it, except for the preference to RB_STREAM_CHUNKED when,
>>perhaps, we could be more sub-optimal, falling back on RB_SPOOL_CL.
>>
>>Many RB_STREAM_CL choices, before, were equally dangerous, and that
>>C-L == length_read test in the stream_reqbody_chunked() was meant
>>to exclude future abuse.
>
>We should be sending C-L if the brigade includes the entire message.
>CL is always preferred for requests. The only time we should send
>T-E on a proxied request is if we cannot buffer enough of the
>received request to know how large it will be.
++1 and committed! The solution was blindingly obvious, try to
fetch MAX_MEM_SPOOL bytes, and determine if we hit EOS before
proceeding to elect -any- C-L or T-E method :)
The logic works out like this once it exceeds MAX_MEM_SPOOL;
was it T-E?
Unless the user overrides by setting proxy-sendcl or by
setting force-proxy-downgrade-1.0, keep using T-E.
proxy-sendchunks causes proxy-sendcl to be ignored for this case.
was it C-L?
Only stream (for unfiltered requests) or spool as C-L, unless
the user overrides with proxy-sendchunks (probably to specific
applications or servers that they are certain will handle
chunked request bodies effectively.)
proxy-sendcl causes proxy-sendchunks to be ignored for this case.
Question for folks familiar with the input stack; should we loop
until MAX_MEM_SPOOL is hit, or is one call to the filter (as my
patch has done) enough to get about MAX_MEM_SPOOL bytes?
>> * No longer upgrade HTTP/1.0 requests to the origin server as
>> HTTP/1.1 unless the force-proxy-request-1.1 envvar is set.
>> [William Rowe]
>
>-1 (veto), since it is a clear violation of
> http://www.ietf.org/rfc/rfc2145.txt
>and the intent of HTTP versions.
Thanks! Reverted.
Bill
