httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r218978 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
Date Fri, 15 Jul 2005 17:57:32 GMT
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  


Mime
View raw message