httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: mod_proxy http request body code review request
Date Mon, 12 Sep 2005 02:40:33 GMT
Further details (as I've promised for any query or objection)...

Jeff Trawick wrote:
> Here's the "why" for normally using chunked encoding to origin server
> if client sent to our proxy using chunked encoding:
> If origin server doesn't support chunked, it wasn't going to work
> bypassing this proxy or using some other proxy implementations anyway;
> therefore unlikely that client code would be chunking to a server that
> doesn't support it (if this configuration only works when an uplevel
> Apache proxy is in the middle, admin can go a step further and use the
> sendcl setting to convert from chunked to cl)

Let's take one quick look;

     if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(input_brigade))) {
         /* The whole thing fit, so our decision is trivial, use
          * the filtered bytes read from the client for the request
          * body Content-Length.
          * If we expected no body, and read no body, do not set
          * the Content-Length.
         if (old_cl_val || old_te_val || bytes_read) {
             old_cl_val = apr_off_t_toa(r->pool, bytes_read);
         rb_method = RB_STREAM_CL;

this case above is by Roy's insistance that, once we preread the small
in-memory buffer, we elect C-L always.  Every HTTP app must be able to
handle a C-L request.  Note we ignore other T-E flavors here (other than
'chunked') because we rejected them outright earlier, and the httpd
server API doesn't have a mechanism to handle non-chunked T-E bodies.

     else if (old_te_val) {
         if (force10
              || (apr_table_get(r->subprocess_env, "proxy-sendcl")
                   && !apr_table_get(r->subprocess_env, 
"proxy-sendchunks"))) {
             rb_method = RB_SPOOL_CL;
         else {
             rb_method = RB_STREAM_CHUNKED;

this case above is what I mentioned, that in almost any case, if we had
a T-E in the first place, and no demand (e.g. HTTP/1.0, or proxy-sendcl)
to use C-L, we will continue to use T-E.  Note that if the user toggles
both proxy-sendcl and proxy-sendchunks, sendchunks will win.

> This is of interest because using chunked potentially results in lower
> resource use.

Could you provide an example of how a 16384 byte or smaller body could
ever be handled more quickly with T-E: chunked, rather than C-L: n
(<=16384)?  I can think of many cases (mostly our own) which are more
efficient when responding with a T-E, but never a case that it's faster
for the client to handle T-E rather than C-L.


View raw message