[Dancer-users] Reverse-proxy deployments
kapranoff at gmail.com
Fri Dec 17 15:17:27 CET 2010
On Fri, Dec 17, 2010 at 15:54, Flavio Poletti <polettix at 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"
> On Fri, Dec 17, 2010 at 12:12 PM, sebastian de castelberg <
> sebu at kpricorn.org> wrote:
>> > 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
>> 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).
> Dancer-users mailing list
> Dancer-users at perldancer.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dancer-users