Proxy base URL seems does not work as expected

I would add a comment here, as after reading this one more time, I will clarify a bit the problem...

I need to specify a proxy base like http://mysite.mydomain/tools/. I have specificed a proxy base of http://mysite.mydomain/tools/ but the URL that shows up in Geoserver is only http://mysite.mydomain/geoserver instead of http://mysite.mydomain/tools/geoserver. Everything after http://mydomain.mysite/ seems to be ignored.

Saul, you should be familiar with the proxy code. Does anything in this report ring a bell for you? Like, knowing more or less where the issue could be in the code?

One more comment, in my case, this does not seem to affect anything other than the default UI, which I do not want to be exposed anyway. In my case, http://www.who.int/tools/geoserver/ should expose the default admin UI, which I do not want, except through my intranet. However requests such as
http://www.who.int/tools/geoserver/wfs?request=GetCapabilities will work, due to rules defined in my proxy.

Hmm. Nothing jumps out at me. I'll try doing it with extra trailing directories and see if it fails for me in the same way.

Jason: just to confirm, this is on 1.6.0_RC2, right?

OK, I just looked at this and I'm somehow convinced that the problem has to do with using absolute paths in the jsp construction in geoserver.

I think that struts is creating paths with code like this (although I have no idea where...)

<a href="/geoserver/config/index.do">main</a>

I tried poking around in "menuator.jsp" to see if I could figure out what was going on in there, but it was pretty obscure.

Note that the proxy_url is completely respected inside all the WMS/WFS/WCS code...this is purely a UI problem with disregarding the subsequent path information after the host info. How does the UI know how to write its links? Where is the UI hooked up to the PROXY_URL info? That point might have more of an answer...

Using GeoServer 1.6.2, this bug persists.

I'm trying to install GS in http://www.publicserver.org/subdirectory/geoserver/ from http://myintranetserver:8080/geoserver

Using Apache:

ProxyPass /subdirectory/ http://myintranetserver:8080/
ProxyPassReverse /subdirectory/ http://myintranetserver:8080/

Proxy base URL: http://www.publicserver.org/subdirectory/

GetCapabilities URLs and contents are ok:
http://www.publicserver.org/subdirectory/geoserver/wcs?service=WCS&request=GetCapabilities
http://www.publicserver.org/subdirectory/geoserver/wms?service=WMS&request=GetCapabilities
http://www.publicserver.org/subdirectory/geoserver/wfs?service=WFS&request=GetCapabilities

but UI is broken with URLs like these:
http://www.publicserver.org/geoserver/demo.do;jsessionid=p7jks7s9jbii
http://www.publicserver.org/geoserver/config/index.do;jsessionid=p7jks7s9jbii

HTML code looks like this:

********************
<a href="/geoserver/config/index.do;jsessionid=p7jks7s9jbii" style="" title="Configuration of GeoServer application">Config</a>

</td>
</tr>

<tr>
<td>

<a href="/geoserver/demo.do;jsessionid=p7jks7s9jbii" style="" title="Here is the demo page for Geoserver. Look here for examples on how to use Geoserver on its own and with other tools.">Demo</a>
*********************

I looked into this a bit, unfortunatley it seems it's going to require extensive changes. All the jsp pages do have a baseUrl, but then all links are using something /path/to/url, the initial / makes the browser link to the geoserver root anyways forgetting about the extra items in the path...

Looked more. The links in our UI are generated by struts using <html:link forward="forwardName"> where forward is a forward to an action in struts.xml, such as "config", or in tiles-defs.xml.
Unfortunately I have no understanding oh how the UI is put togheter (the person that coded it is long gone) and I can't find the definition of various forwards used in the UI, so I guess this one will stay unsolved until we redo the UI with a different technology

ok, worked on the issue with the decision we took of getting rid of doing the reverse proxy work at the application level. That is, we're currently handling the links in the ui in order to adapt all urls to the proxy base url if there's a proxy url set in geoserver.
The point is that proxy base url is, or should be, only to set up friendly urls in our OWS responses, like schema locations and the like, not to do the job of the reverse proxy. This way, a site wanting to expose the ui through a proxy server can still do that by properly configuring the proxy server, without breaking the configuration from inside the local server or intranet

Jason I'm marking the issue resolved waiting for you to test it out.
For your specific use case, it would be enough testing to pick up tonights nightly and verify you can normally use the config ui through your intranet even with a baseProxyUrl set up in geoserver.

Closing the issue, I've tested deeply for a while now and also added a fully working reverse proxy filter that can be enabled through web.xml if exposing the UI through the proxy server is needed