[Update: be sure to read the comments. Philippe has added some very valuable information there]
I’m in the process of putting a VA Smalltalk based Seaside application online on a Linux Server. The server serves multiple applications and static web sites, so I had to use mod_proxy to forward a certain url to the Smalltalk image.
So my httpd.conf for this virtual host looks like this (I left out some stuff so we can concentrate on the topic here):
# set server name
# rewrite incoming requests
RewriteRule ^/files/(.*) http://localhost:8080/files/$1 [proxy,last]
RewriteRule ^/(.*)$ http://localhost:8080/MyApplication/$1 [proxy,last]
I read on the Seaside mailing list that ProxyPreserveHost On makes Apache hand over the URL that the user sees in her browser to Seaside. And somehow I expected this URL to be available in the application’s url by sending
self application url.
It turns out this isn’t the case. All there is is /MyApplication?_s=…
I was somehow expecting that one of WAApplications variables (basicUrl, serverHostname, serverPath, serverPort and whatever) would be filled with any of the parameters. But looking at WAServerAdaptor>>#requestFor: it gets clear that this cannot be the case. At least not on VA ST and also not in Pharo 1.3 wth Seaside 3.06. In the end this means that using mod_proxy does not change the contents of the url that is handed into the Smalltalk image at all, it just makes sure all requests are forwarded to the Smalltalk image.
At our Smalltalk Inspect Fest I got the the tip (thanks, Norbert!) to use
self requestContext request url.
Which returns the very same url.
Debugging around a little (again with some help from Norbert), I found out that what I was looking for is in the ‘referer’ header of the HTTP-Request. Again, this has nothing to do with mod_proxy, the requesting url is also in the referef header on a local machine where there is not even Apache installed.
So here’s what I’m using now to find out which URL the user entered in their browser:
(WAUrl absolute: self requestContext request referer) withoutQuery
What’s it good for?
IN many cases it is not really necessary to know what URL a user requested, as long as the proxy forwards requests to the Smalltalk image, so many Seaside applications may not need this info anyways. In my case I needed it to send out a link by mail which a user can click to get to a certain page and confirm an action. I wanted to be able to use some functionality within the image that does not need to be configured (a possible point of failure) for the development, test and production environments.