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