You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2020/05/30 12:14:27 UTC

Modern/simpler "proxy-send*" envs in trunk

How about we replace all the "proxy-send{cl,chunks,chunked}" logic in
mod_proxy_http (trunk only) with a single (inverse)
"proxy-no-chunked"?

I think almost all backends nowadays support "chunked"
transfer-encoding, so the default would be to use it when we can't
determine content-length (because the client body is already chunked
or because an input filter may change the length of the body).

By doing this we avoid spooling by default, with associated latency,
and filesystem filling up, and ... you name it.
By the way we also avoid three `apr_table_get(r->subprocess_env, ..)`
calls per request, and simplify the code.

For the rare cases (IMHO) where the origin server really does not
support T-E, there would be "proxy-no-chunked", which would spool when
necessary.

Thoughts? (before I propose a patch..)


Regards;
Yann.

Re: Modern/simpler "proxy-send*" envs in trunk

Posted by Eric Covener <co...@gmail.com>.
On Sat, May 30, 2020 at 8:14 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> How about we replace all the "proxy-send{cl,chunks,chunked}" logic in
> mod_proxy_http (trunk only) with a single (inverse)
> "proxy-no-chunked"?
>
> I think almost all backends nowadays support "chunked"
> transfer-encoding, so the default would be to use it when we can't
> determine content-length (because the client body is already chunked
> or because an input filter may change the length of the body).
>
> By doing this we avoid spooling by default, with associated latency,
> and filesystem filling up, and ... you name it.
> By the way we also avoid three `apr_table_get(r->subprocess_env, ..)`
> calls per request, and simplify the code.
>
> For the rare cases (IMHO) where the origin server really does not
> support T-E, there would be "proxy-no-chunked", which would spool when
> necessary.


+1 i have always found this area confusing and fewer spooling cases
(while retaining the spool-to-mem and prefetch stuff) looks good.
I find most "disable chunked encoding" workarounds are just changing a
symptom/error message anyway.

Re: Modern/simpler "proxy-send*" envs in trunk

Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, May 30, 2020 at 2:14 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> Thoughts? (before I propose a patch..)

FWIW, the patch would look like the attached one.

Still with the aim of modernization, could we remove "proxy-sendextracrlf"?