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