httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kalu┼ża <>
Subject Re: mod_proxy's aside connections proposal
Date Tue, 03 Mar 2015 11:29:29 GMT
On 09/30/2014 04:47 PM, Yann Ylavic wrote:
> Hello,
> I have proposed a patch for PR39673 but I'm not sure it would be
> accepted for mainline httpd, so here I am.


I would like to get more opinions on the patch Yann proposed in this 
email. I fully understand that NTLM is not HTTP/1.1 compatible, because 
it's not stateless. The question here is if we want to use the approach 
Yann showed in this patch or we would say that we won't support 
protocols like that.

Jan Kaluza

> The patch adds the possibility (for a module) to acquire a connection
> aside from the worker's reslist, so that it won't be acquired from the
> reslist nor put back to it once released (nor reused for another
> client connection, unless the module does it on its own).
> The connection is still "bound" to a worker, hence it will be
> established/closed according to the worker's configuration (hostname,
> port, SSL, is_address_reusable, TTL...), and the module can still (and
> should) call ap_proxy_determine_connection(),
> ap_proxy_connect_backend() and ap_proxy_release_connection() to do
> that work.
> The new function to acquire an aside connection is :
> PROXY_DECLARE(int) ap_proxy_acquire_connection_ex(const char *proxy_function,
>                                                    proxy_conn_rec **conn,
>                                                    proxy_worker *worker,
>                                                    server_rec *s, void *baton,
>                                                    ap_proxy_acquire_fn acquire,
>                                                    ap_proxy_release_fn release);
> When called with both baton and acquire set to NULL,
> ap_proxy_acquire_connection_ex() is the same as
> ap_proxy_acquire_connection(), and will acquire connections from the
> reslist.
> When acquire is not NULL, it is used as the constructor for *conn
> (given the baton), so it's up to the caller to create a new (aside)
> connection (with the new function ap_proxy_aside_connection() also
> provided) or reuse an existing one according to its criteria (and the
> baton). If release is not NULL, it will be called upon
> ap_proxy_release_connection() with the same baton.
> When acquire is NULL but baton isn't, a built-in acquire function is
> used to select an existing or create a new connection associated to a
> conn_rec (and still the worker). The baton is assumed to be a conn_rec
> (eg. the one of the client's connection), and this mode is hence a
> return back to the days of httpd <= 2.0.
> This is the trick to respond to PR39673 (NTLM forwarding), or any
> issue due to a session associated to a TCP connection (some
> load-balancers configured to do so expect that), which mod_proxy can't
> forward currently.
> The patch then uses the new ap_proxy_acquire_connection_ex() function
> (latter mode) in mod_proxy_http and mod_proxy_ajp (which both have the
> ability to reuse connections), but only when the environment var
> "proxy-aside-c" is defined. This allows for the administrator to use
> SetEnv[If] or a RewriteRule to enable the functionality, according to
> specific conditions, like (PR39673) :
>      RewriteCond %{HTTP:Authorization} ^NTLM
>      RewriteRule ^ - [E=proxy-aside-c]
> The patch is attached, and I tried to make it as generic as I could so
> that it is not PR39673 (NTLM) specific, aside connections looks like a
> nice to have for modules.
> This version is slightly different from the one proposed in the PR, in
> that it will always close aside connections associated with a
> non-reusable worker upon release (the PR's one failed to do that), and
> the default release callback (when none is given) for aside
> connections is now to apply the worker's configured TTL (if any).
> Do you think this can/should (not) be applied to httpd?
> Regards,
> Yann.

View raw message