Alias within Location: loss of PATH_INFO

2016-12-18 Thread Blaise 

(NB: Below is a synthetic test; in real world, this breaks hgweb, for example; 
also, for script handlers, meddling with AcceptPathInfo is not needed.)

Consider the following sample configuration:
--8<--
Alias /test "${site}/test/test.ssi.txt"

AcceptPathInfo on
Options +Includes
AddOutputFilter includes .ssi
Require all granted

--8<--
The said test file (which is a plain text file containing only ""), when invoked as http://example.com/test/path , has the following correct 
environment:
--8<-- PART A -- same in this case and in the case below
DOCUMENT_ROOT=/var/www/common/empty
REQUEST_URI=/test/path
QUERY_STRING=
DOCUMENT_URI=/test/path
DOCUMENT_NAME=test.ssi.txt
DOCUMENT_ARGS=
SCRIPT_FILENAME=/var/www/test/test.ssi.txt
--8<-- PART B -- going to change in the case below
SCRIPT_NAME=/test
CONTEXT_PREFIX=/test
CONTEXT_DOCUMENT_ROOT=/var/www/test/test.ssi.txt
PATH_INFO=/path
PATH_TRANSLATED=/var/www/common/empty/path
DOCUMENT_PATH_INFO=/path
--8<--
However, if the Alias directive is moved into Location:
--8<--

AcceptPathInfo on
Alias "${site}/test/test.ssi.txt"
Options +Includes
AddOutputFilter includes .ssi
Require all granted

--8<--
then the B part of the environment changes to:
--8<-- new PART B -- changed
SCRIPT_NAME=/test/path
CONTEXT_PREFIX=
CONTEXT_DOCUMENT_ROOT=/var/www/common/empty
--8<--
Id est, the context "/test" is lost, and the attribution of "/path" is changed 
from PATH_INFO to SCRIPT_NAME.
Am I correct to understand that this is an implementation bug; or at very least 
a documentation bug? (since I cannot find anything related under 
https://httpd.apache.org/docs/trunk/mod/mod_alias.html#alias )

(I tested this with httpd.x86_64 version 2.4.23-5.fc25 on Fedora Server, and I 
browsed through the bug tracker to check if this was reported/fixed recently.)

--
βþ

ScriptAlias with a specific handler

2016-06-29 Thread Blaise 

ScriptAlias seems to have an unfair preference for mod_cgi, since the handler 
"cgi-script" is hard-coded in mod_alias.
Would it not be nicer (towards other scripting modules and the user) if 
ScriptAlias accepted an optional third parameter -- handler's name, so that one 
could write
ScriptAlias /webapp "/path/to/webapp" custom-script-processor
instead of
Alias /webapp "/path/to/webapp"

Options +ExecCGI
SetHandler custom-script-processor

?

--
βþ

Re: Looking to TR 2.4.8 in Feb...

2014-01-06 Thread Blaise Tarr 
On Mon, Jan 6, 2014 at 1:17 PM, Daniel Ruggeri drugg...@primary.net wrote:

 One more vote for the UDS patch would be appreciated if anyone could
 spare a moment to have a look. Happy New Year all, BTW.

I tried the UDS patch in httpd trunk with mod_proxy_fcgi and PHP-FPM,
and ProxyPass is working nicely now. I used the following config:

LocationMatch ^(.*\.php)$
ProxyPass unix:/tmp/php-fpm.sock|fcgi://PHP1${DOCROOT}
/LocationMatch

One thing worth pointing out is that some unique dummy hostname, such
as that PHP1 in the above example, is required after the real
scheme. It might be tempting to pick localhost, but that would
result in problems when using multiple sockets.

Next I tried using UDS with mod_rewrite, but I couldn't get that to
work. Using this config:

RewriteRule /php-info
unix:/tmp/php-fpm.sock|fcgi://${DOCROOT}/ppp/info.php [P,L]

with this URL:

http://localhost:8000/php-info

I got a 404. Turning on tracing for mod_rewrite:

[Mon Jan 06 13:56:25.653655 2014] [rewrite:trace2] [pid 15211:tid
140236536502016] mod_rewrite.c(472): [client ::1:49459] ::1 - -
[localhost/sid#21a5a58][rid#7f8b44002970/initial] rewrite '/php-info'
- 
'unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php'
[Mon Jan 06 13:56:25.653672 2014] [rewrite:trace2] [pid 15211:tid
140236536502016] mod_rewrite.c(472): [client ::1:49459] ::1 - -
[localhost/sid#21a5a58][rid#7f8b44002970/initial] forcing
proxy-throughput with
http://localhost:8000/unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[Mon Jan 06 13:56:25.653702 2014] [rewrite:trace1] [pid 15211:tid
140236536502016] mod_rewrite.c(472): [client ::1:49459] ::1 - -
[localhost/sid#21a5a58][rid#7f8b44002970/initial] go-ahead with proxy
request 
proxy:http://localhost:8000/unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[OK]

So mod_rewrite is not recognizing the unix: prefix as being valid. I
temporarily commented out the call of fully_qualify_uri(r) at
mod_rewrite.c:4130, and now r-filename is set correctly:

[Mon Jan 06 14:30:47.758212 2014] [rewrite:trace2] [pid 20870:tid
140038133200640] mod_rewrite.c(472): [client ::1:50308] ::1 - -
[localhost/sid#2535a58][rid#7f5d14002970/initial] rewrite '/php-info'
- 
'unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php'
[Mon Jan 06 14:30:47.758226 2014] [rewrite:trace2] [pid 20870:tid
140038133200640] mod_rewrite.c(472): [client ::1:50308] ::1 - -
[localhost/sid#2535a58][rid#7f5d14002970/initial] forcing
proxy-throughput with
unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[Mon Jan 06 14:30:47.758253 2014] [rewrite:trace1] [pid 20870:tid
140038133200640] mod_rewrite.c(472): [client ::1:50308] ::1 - -
[localhost/sid#2535a58][rid#7f5d14002970/initial] go-ahead with proxy
request 
proxy:unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[OK]
[Mon Jan 06 14:30:47.758379 2014] [proxy:trace2] [pid 20870:tid
140038133200640] proxy_util.c(1932): [client ::1:50308] *: found
reverse proxy worker for
unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[Mon Jan 06 14:30:47.758392 2014] [proxy:debug] [pid 20870:tid
140038133200640] mod_proxy.c(1138): [client ::1:50308] AH01143:
Running scheme unix handler (attempt 0)
[Mon Jan 06 14:30:47.758403 2014] [proxy_fcgi:debug] [pid 20870:tid
140038133200640] mod_proxy_fcgi.c(770): [client ::1:50308] AH01076:
url: 
unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
proxyname: (null) proxyport: 0
[Mon Jan 06 14:30:47.758411 2014] [proxy_fcgi:debug] [pid 20870:tid
140038133200640] mod_proxy_fcgi.c(773): [client ::1:50308] AH01077:
declining URL 
unix:/tmp/php-fpm.sock|fcgi:///data/local/build/apache/inst/htdocs/ppp/info.php
[Mon Jan 06 14:30:47.758418 2014] [proxy:warn] [pid 20870:tid
140038133200640] [client ::1:50308] AH01144: No protocol handler was
valid for the URL /php-info. If you are using a DSO version of
mod_proxy, make sure the proxy submodules are included in the
configuration using LoadModule.

but this results in a 500. It looks like mod_proxy is not ready for a
UDS URI in r-filename when it was set by some other module earlier in
the request.

-- 
Blaise

Re: UDS support in mod_proxy (trunk)

2013-10-21 Thread Blaise Tarr 
On Fri, Oct 18, 2013 at 9:30 AM, Jim Jagielski j...@jagunet.com wrote:

 UDS support in mod_proxy is at a stage for some serious
 testing...

Tested with httpd SVN trunk r1534292 plus apr SVN trunk r1534314.

First I verified that mod_proxy_fcgi works as expected with TCP sockets
using this config:

# PHP-FPM listening on localhost port 9070
# docroot is /var/opt/content-8003/
LocationMatch ^(.*\.php)$
ProxyPass fcgi://localhost:9070/var/opt/content-8003/
/LocationMatch

and of course that worked. Then I tried with UDS using this config:

# PHP-FPM listening on UDS /var/opt/php-fpm/s8071/run/php-fpm.sock
# docroot is /var/opt/content-8003/
LocationMatch ^(.*\.php)$
ProxyPass
unix:/var/opt/php-fpm/s8071/run/php-fpm.sock|fcgi:///var/opt/content-8003/
/LocationMatch

but got this error:

[Mon Oct 21 12:43:15.042260 2013] [proxy:warn] [pid 6575:tid 1157982528]
[client 10.17.35.38:56195] AH01144: No protocol handler was valid for the
URL /info.php. If you are using a DSO version of mod_proxy, make sure the
proxy submodules are included in the configuration using LoadModule.

I haven't yet had a chance to investigate further.

-- 
Blaise

Re: uds support

2013-10-15 Thread Blaise Tarr 
On Tue, Oct 15, 2013 at 1:01 PM, Jim Jagielski j...@jagunet.com wrote:

 I went ahead and made an exec decision to baseline

 unix:/path/to/sock.sock|http:

 as canon. trunk now does this.

Jim, thanks for working on this. With this latest approach how is the URI
path specified? For example, with the original patch which relied on the
URL encoded slashes we could have:

ProxyPass fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/

How would that look now (specifically the /local/htdocs portion)?

-- 
Blaise

Re: [PATCH] mod_proxy Unix domain socket support

2013-02-26 Thread Blaise Tarr 
Hello,

I updated my patch which adds Unix domain socket support to mod_proxy
to resolves a problem on BSD systems. The patch is against Apache
2.4.4. Please see this bugzilla for the details:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c1

Thanks,
Blaise

[PATCH] mod_proxy Unix domain socket support

2012-07-31 Thread Blaise Tarr 
Hi,

The attached patch adds support for Unix domain sockets (UDS) to
mod_proxy. This is very beneficial when configuring a reverse proxy
using mod_proxy_fcgi to connect to PHP-FPM. In some tests with ab
there was over 20% improvement in the request rate when using a UDS
instead of TCP.

Since remote servers in mod_proxy are configured with a URL, I took
the idea from this page on how to represent a UDS as a URL:
http://daniel.haxx.se/blog/2008/04/14/http-over-unix-domain-sockets/

So the host portion of the URL contains socket= followed by the URI
encoded socket path (upper case characters must be encoded too). Below
are a couple of examples where PHP-FPM's socket is /tmp/php-fpm.sock
and the document root is /local/htdocs:

ProxyPass fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/

RewriteRule (.*\.php) fcgi://socket=\%2ftmp\%2fphp-fpm.sock/local/htdocs/$1 
[P,L]

The following are not contained in the patch:
* bump MMN due to mod_proxy.h changes
* assign APLOGNO numbers
* detection of AF_UNIX support in configure

Thanks for your consideration,
Blaise
diff -ur httpd-2.4.2/modules/proxy/mod_proxy.h 
httpd-2.4.2_uds/modules/proxy/mod_proxy.h
--- httpd-2.4.2/modules/proxy/mod_proxy.h   2012-03-31 08:40:36.0 
-0700
+++ httpd-2.4.2_uds/modules/proxy/mod_proxy.h   2012-07-27 09:44:16.0 
-0700
@@ -231,6 +231,7 @@
 * that is used over the backend connection. */
 proxy_worker *worker;  /* Connection pool this connection belongs to */
 apr_pool_t   *pool;/* Subpool for hostname and addr data */
+const char   *uds_path;/* Unix domain socket path */
 const char   *hostname;
 apr_sockaddr_t *addr;  /* Preparsed remote address info */
 apr_pool_t   *scpool;  /* Subpool used for socket and connection data 
*/
@@ -302,9 +303,9 @@
 #define PROXY_WORKER_MAX_SCHEME_SIZE16
 #define PROXY_WORKER_MAX_ROUTE_SIZE 64
 #define PROXY_BALANCER_MAX_ROUTE_SIZE PROXY_WORKER_MAX_ROUTE_SIZE
-#define PROXY_WORKER_MAX_NAME_SIZE  96
+#define PROXY_WORKER_MAX_NAME_SIZE  368
 #define PROXY_BALANCER_MAX_NAME_SIZE PROXY_WORKER_MAX_NAME_SIZE
-#define PROXY_WORKER_MAX_HOSTNAME_SIZE  64
+#define PROXY_WORKER_MAX_HOSTNAME_SIZE  336
 #define PROXY_BALANCER_MAX_HOSTNAME_SIZE PROXY_WORKER_MAX_HOSTNAME_SIZE
 #define PROXY_BALANCER_MAX_STICKY_SIZE  64
 
diff -ur httpd-2.4.2/modules/proxy/proxy_util.c 
httpd-2.4.2_uds/modules/proxy/proxy_util.c
--- httpd-2.4.2/modules/proxy/proxy_util.c  2012-03-31 08:40:36.0 
-0700
+++ httpd-2.4.2_uds/modules/proxy/proxy_util.c  2012-07-30 11:57:01.0 
-0700
@@ -31,6 +31,12 @@
 #define apr_socket_create apr_socket_create_ex
 #endif
 
+#define HAVE_AF_UNIX 1
+#if HAVE_AF_UNIX
+#include sys/un.h
+#include apr_support.h/* for apr_wait_for_io_or_timeout() */
+#endif
+
 APLOG_USE_MODULE(proxy);
 
 /*
@@ -1965,6 +1971,7 @@
 (*conn)-worker = worker;
 (*conn)-close  = 0;
 (*conn)-inreslist = 0;
+(*conn)-uds_path = NULL;
 
 return OK;
 }
@@ -1981,6 +1988,30 @@
 return OK;
 }
 
+/*
+ * Decodes a '%' escaped string, and returns the number of characters
+ */
+static int decodeenc(char *x)
+{
+int i, j, ch;
+
+if (x[0] == '\0') {
+/* special case for no characters */
+return 0;
+}
+for (i = 0, j = 0; x[i] != '\0'; i++, j++) {
+/* decode it if not already done */
+ch = x[i];
+if (ch == '%'  apr_isxdigit(x[i + 1])  apr_isxdigit(x[i + 2])) {
+ch = ap_proxy_hex2c(x[i + 1]);
+i += 2;
+}
+x[j] = ch;
+}
+x[j] = '\0';
+return j;
+}
+
 PROXY_DECLARE(int)
 ap_proxy_determine_connection(apr_pool_t *p, request_rec *r,
   proxy_server_conf *conf,
@@ -2075,10 +2106,17 @@
 conn-port = uri-port;
 }
 socket_cleanup(conn);
-err = apr_sockaddr_info_get((conn-addr),
-conn-hostname, APR_UNSPEC,
-conn-port, 0,
-conn-pool);
+if (strncmp(conn-hostname, socket=, 7) == 0) {
+char *uds_path = apr_pstrdup(conn-pool, conn-hostname + 7);
+decodeenc(uds_path);
+conn-uds_path = uds_path;
+}
+else {
+err = apr_sockaddr_info_get((conn-addr),
+conn-hostname, APR_UNSPEC,
+conn-port, 0,
+conn-pool);
+}
 }
 else if (!worker-cp-addr) {
 if ((err = PROXY_THREAD_LOCK(worker)) != APR_SUCCESS) {
@@ -2302,6 +2340,50 @@
 }
 
 
+/* lifted from mod_proxy_fdpass.c; tweaked addrlen in connect() call */
+static apr_status_t socket_connect_un(apr_socket_t *sock,
+  struct sockaddr_un *sa)
+{
+apr_status_t rv;
+apr_os_sock_t rawsock;
+apr_interval_time_t t;
+
+rv

Re: [PATCH] Re: proxy cgi no longer streamed, C-L filter buffers

2002-08-19 Thread Blaise Tarr 

Brian Pane writes:
  Blaise Tarr wrote:
  
  With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
  streamed to the client but sent in one big chunk.
 
  Here's a patch that removes the buffering.  Let me know if
  it solves the proxy streaming problem.

Thanks Brian.  It's much better now, but it still buffers in 8K chunks
as opposed to the 2.0.32 behavior where there was no apparent
buffering.

thanks,

Blaise

proxy cgi no longer streamed, C-L filter buffers

2002-08-15 Thread Blaise Tarr 

With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
streamed to the client but sent in one big chunk.  It appears that the
C-L filter now buffers the data in every case.  For certain
applications this is a very undesirable feature, and it would be very
helpful if the C-L filter could be bypassed (and simply not send back
a C-L header).  In 2.0.32 streaming behaved beautifully.  Then in
2.0.36 and 2.0.39 the C-L filter started buffering large chunks.  Now
in 2.0.40 everything is buffered and a C-L header is always inserted.
Could the 2.0.32 streaming/C-L behavior be brought back, perhaps
enabled by a config option?

Blaise