I guess the main question is what are the actual use-cases?
> On Mar 3, 2015, at 6:29 AM, Jan Kaluža <jkal...@redhat.com> wrote:
>
> 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.
>
> Hi,
>
> 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.
>
> Regards,
> 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.
>>
>
