[Dancer-users] Reverse-proxy deployments

[Flavio Poletti]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101215/90fa310a/attachment.htm>