Details
-
Bug
-
Resolution: Done
-
Major
-
7.1.1.Final
-
None
Description
The HTTP interface uses relative address in Location header when redirecting:
$ curl -v localhost:9990 * About to connect() to localhost port 9990 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 9990 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: localhost:9990 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Transfer-encoding: chunked < Location: /console/index.html < Date: Wed, 04 Apr 2012 12:50:14 GMT < * Connection #0 to host localhost left intact * Closing connection #0
This is a problem running a reverse proxy to server the console. RFC 1945 requires that to be a complete absolute URI [1]. The problem is that mod_proxy expects a complete URI. The problem manifests when proxying is performed on path other than ROOT of the http server (e.g. you open http://server_public_hostname/asconsole to access console). A typical mod_proxy configuration in this case would be:
ProxyPass /asconsole/ http://localhost:9990/ ProxyPassReverse /asconsole/ http://localhost:9990/ ProxyPassReverseCookiePath / /asconsole/ ProxyPassReverseCookieDomain localhost server_public_hostname
redirects in this case are not translated by mod_proxy because it matches against string "http://localhost:9990/". And one is redirected to /something instead of /asconsole/something.
curl output:
curl -v http://my_public_hostname/asconsole
* About to connect() to my_public_hostname port 80 (#0)
* Trying 24.24.164.76... connected
* Connected to my_public_hostname (24.24.164.76) port 80 (#0)
> GET /asconsole HTTP/1.1
> User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: my_public_hostname
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 04 Apr 2012 12:29:30 GMT
< Location: /console/index.html
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/plain; charset=UTF-8
<
* Closing connection #0
The workarounds are described in the workaround section.
I'm not really sure what the best approach for this problem would be. Using the Host header of request makes some sense but if one already uses ProxyPreserveHost On then it can also affect this functionality. Hardcoding the URL would be a complication to configuration. Perhaps making the behavior configurable and documented would be best.
Attachments
Issue Links
- is related to
-
-
- Resolved
-
