[Dancer-users] Reverse-proxy deployments

[Flavio Poletti]

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