redirect messes up with https URIs

[sukria]

Hi,

At work we have an Apache frontend that listens on the 443 port. Behind that we have some Starman workers. When the application issues a relative redirect (eg: /login), Dancer tries to rebuild an absolute URI (because of RFC 2616, according to the source) and just ignores the original URI scheme.

This leads to the following unwanted behaviour:

 https://some.app.com/ -> redirect '/login'; -> Location: http://some.app.com/login # wich is bad

Removing the RFC2616 code bloc fixes the issue, but keeps the URI relative...

We need a way to fix that...

[bigpresh]

I think the fix is to look at the X-Forwarded-Protocol (OTTOMH) header to determine the protocol of the original request, and if it's set, use that. This should probably be configurable so that it only happens if you set a config setting to indicate that your app is behind a proxying front end which will set those headers, otherwise they shouldn't be trusted, as they could be from the client.

The request source IP should also be taken from the X-Forwarded-For header in that case also.

This was discussed on IRC recently, I think someone was starting work on that feature already; I'll need to search my logs to confirm.

[sukria]

Thanks for the update @bigpresh :)

Indeed your solution seems reasonable to me.

[sukria]

By the way, this bug is rather important to me (need a fix for it at work), just my two cents to vote for working on that one ASAP ;)

[ambs]

Check #512.

[ambs]

Fixed on #512, already merged.