Wow! Maybe I was a bit too verbose, I'll try to condense in two simple questions: 1. is it possible to set up uri_for to play well in a reverse-proxy environment? 2. what is the best approach to handle static content in a reverse-proxy environment, i.e. having the reverse-proxy handle it directly? Hope to have more luck this time! :-) Cheers, Flavio. On Wed, Dec 15, 2010 at 8:50 AM, Flavio Poletti <polettix@gmail.com> wrote:
Hi All,
just a thought about the reverse-proxy deployment strategy and how you handle it.
First of all, it seems that this approach "burns away" the uri_for function, because it insists on working upon the "internal" URI and not the one seen on the external side. I worked this around by re-defining uri_for and forcing the usage of a configurable base URI, but I'd like to hear whether there is a better/standard/builtin alternative to this. Looking at the code it does not seem that the current implementation of uri_for is ready for a reverse-proxy envinroment, maybe this could be provided as a generalisation of the current uri_for? Maybe with some Dancer::Plugin::ReverseProxy plugin?
Another thing has to do with the static contents. By default this lives in the same "space" as all the routes, although in separate subdirectories. To serve this content statically, it means that each item in the "public" directory within my app tree must be explicitly dealt with by the reverse-proxy server with an ad-hoc configuration, e.g. in Apache I would put:
ProxyPass /path/to/app/css/ ! ProxyPass /path/to/app/javascripts/ ! ProxyPass /path/to/app/images/ ! ProxyPass /path/to/app/favicon.ico ! ProxyPass /path/to/app/ http://www.example.com/killer-app/ ProxyPassReverse /path/to/app/ http://www.example.com/killer-app/
This might be annoying and error-prone: what if I add another directory/item and I forget to change the configuration of the proxy? In this case, the safer approach seems to be the configuration of a "static" directory inside the reverse proxy, which is accessed through http://www.example.com/path/to/app/static/, but this in turn means that the templates have to be modified to include this new "static" subdirectory. This approach is not the default one while creating a new Dancer app, so I'd like if someone can share some thoughts about possible alternatives to this kind of modifications.
Thank you,
Flavio.