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.
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.
hi,
Wow! Maybe I was a bit too verbose, I'll try to condense in two simple questions: much better...;)
1. is it possible to set up uri_for to play well in a reverse-proxy environment? in case your app runs with plack, you may have a look at http://search.cpan.org/~danjou/Plack-Middleware-ReverseProxy-0.06/. if I recall correctly, a redirect issue we had could be fixed with this plugin. it could work for uri_for too.
2. what is the best approach to handle static content in a reverse-proxy environment, i.e. having the reverse-proxy handle it directly? In our low-traffic setup Dancer delivers static content (deployment was much easier).
cheers
Hi sebastian, good to know that the fault was on my side of the question, there's always space for learning something :-) Unfortunately I don't think that the Plack solution is going to work, according to the documentation it should mangle HTTP Headers but uri_for is geared to the generation of the Body. I addressed the problem and solved it with a new uri_for function, I'm curious whether others had the same problem or know more "streamline" solutions. Cheers, Flavio. On Fri, Dec 17, 2010 at 12:12 PM, sebastian de castelberg <sebu@kpricorn.org
wrote:
hi,
Wow! Maybe I was a bit too verbose, I'll try to condense in two simple questions: much better...;)
1. is it possible to set up uri_for to play well in a reverse-proxy environment? in case your app runs with plack, you may have a look at http://search.cpan.org/~danjou/Plack-Middleware-ReverseProxy-0.06/. if I recall correctly, a redirect issue we had could be fixed with this plugin. it could work for uri_for too.
2. what is the best approach to handle static content in a reverse-proxy environment, i.e. having the reverse-proxy handle it directly? In our low-traffic setup Dancer delivers static content (deployment was much easier).
cheers
On Fri, Dec 17, 2010 at 15:54, Flavio Poletti <polettix@gmail.com> wrote:
Hi sebastian,
good to know that the fault was on my side of the question, there's always space for learning something :-)
Unfortunately I don't think that the Plack solution is going to work, according to the documentation it should mangle HTTP Headers but uri_for is geared to the generation of the Body.
uri_for() uses Dancer::Request::base() to determine scheme, host and port from HTTP headers (actually %ENV). And Plack::Middleware::ReverseProxy will set those environments vars to relevant values using common reverse proxy HTTP headers like HTTP_X_FORWARDED_*. So it should work (or base() should be fixed so that this mode works)
I addressed the problem and solved it with a new uri_for function, I'm curious whether others had the same problem or know more "streamline" solutions.
On Fri, Dec 17, 2010 at 12:12 PM, sebastian de castelberg < sebu@kpricorn.org> wrote:
hi,
Wow! Maybe I was a bit too verbose, I'll try to condense in two simple questions: much better...;)
1. is it possible to set up uri_for to play well in a reverse-proxy environment? in case your app runs with plack, you may have a look at http://search.cpan.org/~danjou/Plack-Middleware-ReverseProxy-0.06/. if I recall correctly, a redirect issue we had could be fixed with this plugin. it could work for uri_for too.
2. what is the best approach to handle static content in a reverse-proxy environment, i.e. having the reverse-proxy handle it directly? In our low-traffic setup Dancer delivers static content (deployment was much easier).
cheers
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (3)
-
Alex Kapranoff -
Flavio Poletti -
sebastian de castelberg