httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: 2.4.x with uds patch; FastCGI broken?
Date Sat, 16 Nov 2013 17:47:07 GMT
OK, I think I know what it is, and it's simple (if true),
but a pain.

The issue is that during the proxypass stuff, we tuck away the
name, which may, or may not, include a port designation, depending
on if the URL passed does. All well and good.

The problem is that during the proxy_hook_canon_handler()
phase, some submodules, like fcgi, always attach the port
to the URL if it doesn't include one. http does not; it
only adds it iff the determined port != the default port.

Soooooo when mod_proxy tries to find the correct worker,
because the fcgi URL in ProxyPass didn't have :8000 but
the canon URL will have it added, they will be see
as different, and so the defined worker will not be
used; the default and generic reverse proxy worker will.

We could ensure that when each worker is defined, we always
add the port, even if not provided. But, this will involve
changing proxy_http_canon(). I'm not sure I like this
since it adds additional storage for no real purpose, plus
adds some cycles to the strcasecmp for finding the workers.

Instead, I think that fcgi (and ajp as well), should do their
proxy_*_canon the same as http. However, since apr_uri_port_of_scheme()
doesn't know about these, we need to also create a
ap_proxy_port_of_scheme().

Unless I hear otherwise, that's what I'll be working
on.

Mime
View raw message