httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6 tomorrow)
Date Fri, 04 Apr 2014 22:19:26 GMT
On Fri, Apr 4, 2014 at 7:52 PM, Jim Jagielski <jim@jagunet.com> wrote:
> Is there any way to accomplish w/o using notes? It's not that
> they are especially slow, it's just that they aren't that fast
> and, iirc, this could be a tight path.

There surely is, but we can't use the proxy_conn_rec for this (it may
change between calls for the load-balancing case).
We could define ap_proxy_create_hdrbrgd_ex() which takes the saved
"proxy-interim-response" env as argument (looked up once by the
caller), or add a new request_rec field (...), but I think it's a bit
(at least) overkill for a path where, anyway, expecting (and probably
waiting for) a 100-continue will take much more time than a few
apr_table ops.

The simpler solution, IMHO, is to simply never forward 100-continue
responses, the client has already got one when this happens.
I don't really understand the purpose of "proxy-interim-response" ==
"RFC" anyhow ("suppress" should be the only behaviour), I even think
it is not RFC compliant (at least useless) to send multiple
100-continue...

As said earlier, by pre-fetching the request body, mod_proxy can't be
an expectation proxy: it should comply to the client part of the RFC
wrt to the origin (which is the case), and to the server part of the
RFC wrt the client (which "proxy-interim-response" breaks).

Mime
View raw message