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