On Fri, Apr 4, 2014 at 7:52 PM, Jim Jagielski <j...@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).
