[ https://issues.jboss.org/browse/AS7-4397?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned AS7-4397: ------------------------------------- Assignee: Darran Lofthouse (was: Heiko Braun) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4397?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-4397: ---------------------------------- Summary: http interface uses relative paths for redirections (was: console uses relative paths for redirections) 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) < 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) < 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. [1] http://en.wikipedia.org/wiki/HTTP_location was: Console 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) < 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) < 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. [1] http://en.wikipedia.org/wiki/HTTP_location Component/s: Domain Management (was: Console) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4397?page=com.atlassian.jira.plugin.s... ] Aleksandar Kostadinov updated AS7-4397: --------------------------------------- Description: The HTTP interface uses relative address in Location header when redirecting: {code}$ 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) < 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 {code} 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: {code}ProxyPass /asconsole/ http://localhost:9990/ ProxyPassReverse /asconsole/ http://localhost:9990/ ProxyPassReverseCookiePath / /asconsole/ ProxyPassReverseCookieDomain localhost server_public_hostname {code} 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:{code} 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) < 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 {code} 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. [1] http://en.wikipedia.org/wiki/HTTP_location was: 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) < 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) < 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. [1] http://en.wikipedia.org/wiki/HTTP_location -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4397?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated AS7-4397: ---------------------------------- Fix Version/s: 7.2.0.Alpha1 (was: 7.1.2.Final (EAP)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4397?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on AS7-4397: --------------------------------------- The implementation I will use for this will be to just make use of the supplied Host header - from an AS perspective we can only work with the information that we have available to us so the proxy should be supplying what we need. If the proxy is going to convert the Host header then it should convert the response URL back. If additional configuration is to be performed worst case is to just handle the redirect directly in the proxy and don't rely on the AS side of the redirect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira