Bug 53218 - ProxyPass worker name (http://localhost:3128/...) too long
Summary: ProxyPass worker name (http://localhost:3128/...) too long
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.4.7
Hardware: PC Linux
: P5 blocker with 11 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2012-05-11 01:32 UTC by Makoto Murata
Modified: 2016-08-17 16:32 UTC (History)
5 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Makoto Murata 2012-05-11 01:32:29 UTC

I'm tring to change apache from 2.2 to 2.4.2.
And apachectl reports there is error in my configuration file about proxypass.

# /usr/local/apache24/bin/apachectl -t
AH00548: NameVirtualHost has no effect and will be removed in the next release /usr/local/apache24/conf/httpd.conf:101
AH00526: Syntax error on line 615 of /usr/local/apache24/conf/httpd.conf:
ProxyPass worker name (http://localhost:3128/VirtualHostBase/http/www.hogefuga.com:80/fugafugafile/VirtualHostRoot/++resource++Products.HOGEHOGE.public.stylesheets) too long

I read some sorce files and found there is length limit in worker name.
In mod_proxy.h:305 there is define of length of proxy worker name.


I think in some casees this size is not enough.
In my case (legth is 177 chars.), I doubled this number and works fine.
Would you please increase this size.

Thank you.
Comment 1 kiorky 2014-02-13 17:29:52 UTC
I confirm the bug and second the importance of this bug to be solved.
Comment 2 masc2279 2014-02-25 23:58:22 UTC
I can also confirm the bug. This version is completely useless have to downgrade. Even the hack does not work. Just changing the #define PROXY_WORKER_MAX_NAME_SIZE      96   by itself does nothing at least on my side even if you place a number beyond what is needed it still says too long.
Comment 3 kiorky 2014-02-26 07:02:44 UTC
We got our way using PT rewrites, eg 

# /-> vhmonster proxyreverse because of redirects !
RewriteRule ^/(.*)$ /VirtualHostBase/http/edit.foo.bar.net:80/Plone/VirtualHostRoot/$1 [L,PT]

# for https://issues.apache.org/bugzilla/show_bug.cgi?id=53218, only use a simple worker url
ProxyPass         / retry=1
ProxyPassReverse  /
ProxyPassReverse  /zmiroot/
Comment 4 Alan 2014-07-02 22:50:43 UTC
I can confirm this bug as well on Kubuntu 14.04 LTS 64-bit running Apache 2.4.7.  Unfortunately, it is making it impossible for me to serve Plone pages through Apache, which is preventing me from upgrading my production servers to 14.04 LTS.  It would be great if this issue could be addressed soon.  Thanks.
Comment 5 kiorky 2014-07-03 07:43:12 UTC
Alan, you can use rewrites instead of proxypass, even if it is a bug, this workaround which is more another way to do that  workaround will let you upgrade.

If you are just setting up a proxy, you may also opt for something like nginx.
Comment 6 sebastian 2014-07-27 18:40:51 UTC
I second that. Especially with unix domain sockets allowed in mod_proxy the names can get quite long.
Comment 7 Jim Jagielski 2014-08-29 18:35:06 UTC
I am looking into whether or not that should be a fatal error... we may be able to get around just reporting it, and still using/accepting a truncated copy.
Comment 8 Rainer Jung 2014-09-04 09:21:38 UTC
Maximum worker name length increased by jim to 256 in trunk (and some other limits increased as well). Revisions r1540318, r1621367, r1621372, r1621373, r1621382.
Proposed for backport to 2.4.x.
Comment 9 Rainer Jung 2014-09-04 11:24:01 UTC
There's an API compatibility problem with a straight backport proposal. Backport on hold.
Comment 10 kiorky 2014-09-04 19:06:18 UTC
256 is not enougth !
Comment 11 Rainer Jung 2014-09-08 10:53:46 UTC
There's a workaround available that should be applicable to many situations: combined ProxyPass with RewriteRule [P] flag:

One can do reverse proxying with mod_proxy ProxyPass but also with mod_rewrite RewriteRule [P] flag. The former often is "better", because it uses a pool of persistent connections to the origin server and the characteristics of the connections can be configured in more detail.

What is possible here, is a combination of both approaches: Use a "dummy" ProxyPass with short right side URI to configure a pool to the origin server but RewriteRule for the individual proxy rules containing the long target URLs. As long as the right side of the ProxyPass matches thebeginning of the RewriteRule target URL, the proxying will be done via the connection pool configured with ProxyPass.

An Example:

# This directive must come before the following one in order
# block access to arbitrary URIs on the origin server!
# As an alternative one can also use "RewriteRule /UNUSED - [F]"
ProxyPass /UNUSED !

# Configure a connection pool for the origin server
# http://myserver.example.org:9081
ProxyPass /UNUSED http://myserver.example.org:9081

RewriteEngine On

# Proxy "/long" to a long URI on the origin server,
# [P] flag at end of line is important
RewriteRule /long http://myserver.example.org:9081/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/long.html [P]

# Proxy "/verylong" to an even longer URI on the origin server,
# again [P] flag at end of line is important
RewriteRule /verylong http://myserver.example.org:9081/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd/verylong.html [P]


- you can use long origin server URIs
- the requests are still dispatched to a pool of persistent connections
- You can combine this with ProxyPassReverse and similar directives


- all requests to this origin server will use the same connection pool, not one pool per target URI. This might be a con in some cases (less separation), in some it might actually be a pro (sharing of resources)
- need a combination of two different syntaxes (harder to understand)
- might not work for any protocol to the origin server (ajp, fcgi, scgi etc.), I simply haven't tested it for those.
Comment 12 kiorky 2014-09-08 10:56:42 UTC
if you had read the bug report, you would notice that i posted myself this workaround.
Comment 13 Rainer Jung 2014-09-08 18:10:44 UTC
Sorry. I read much more than this bug report (there's also other discussion going on) and overlooked your workaround in comment #3 above.

Note though that

- your recipe opens up the origin server for any URI via the ProxyPass for "/". Often that is not wanted, therefore my recipe contains the additional and important ProxyPass with a "!". This in turn only makes sense by using some "/UNUSED" instead of simply "/". This change has security implications.

- you are using the pass-through flag "PT", I'm using the proxy flag "P". I didn't try "PT" but "P" seems to be more correct. Your mileage may vary.


Comment 14 Ruediger Pluem 2014-09-08 18:58:32 UTC
Even easier: Create a

<Proxy protocol://server/yourseparationpathprefix>
   SetProxy anyoption

block in your configuration and you are using a connection pool with RewriteRule [P]
Comment 15 Christopher Schultz 2014-12-02 14:20:48 UTC
+1 for increasing the URL length limit for proxy targets.

I ran into this recently with an https:// proxy where the hostname was long, causing the URLs to exceed this limit. Using the IP address was not possible because the HTTPS connection refused to handshake because of a mismatched hostname (IP != cert hostname).

The workaround in my case was to use ProxyPassMatch which is non-ideal as it adds a regular expression evaluation (multiple, since I have many ProxyPassMatch directives) to every request, plus I can't be as specific as I need to when mapping certain URLs and not others.

I would normally use mod_jk, but the client required the use of HTTPS between the reverse proxy and application server (Tomcat, in this case).