RFC: Change redirects/Location header from fully qualified to absolute path URLs

[Daniel Worthington-Bodart]

Hi People,

Originally Utterlyidle used absolute path URLs as all browsers supported it and meant that the app worked nicely behind reverse proxies etc.

Then they changed the HTTP spec to explicitly say that was not allowed (even though everyone supported it) and a security vulnerability was raised against Utterlyidle and so we switch to fully qualified URLs in the Location header. This then meant you had to do stuff in you reverse proxy to rewrite URLs etc which was a pain but hey.

Anyway they recently re-changed the HTTP spec back to allow for absolute path URLs again. So I'd like to switch back but I am worried about breaking changes but I'd also like to make this work as well as possible by default.

My current thoughts are follows:

1. Make BasePathHandler more relaxed and if we get an absolute path URL in a location header allow it to flow though without change.
2. Make Redirector.seeOther by default return an absolute path URL (This is a breaking change)
3. Add a system property that will force the old behaviour in Redirector.seeOther
4. Make BaseUrl support "X-Forwarded-Host" just like we support "X-Forwarded-Proto", this will make it work better behind reverse proxies in general as well as when running in the old mode.

Any comments?

Dan

[Daniel Worthington-Bodart]

For reference the old spec https://tools.ietf.org/html/rfc2616#section-14.30 and the new https://tools.ietf.org/html/rfc7231#section-7.1.2

[Matt Savage]

At what moment in deployment will the breaking change be noticed?

If I only pick it up once I hit a prod-ish environment with a configured reverse proxy, a breaking chance is a bigger deal than usual?

Could force the issue by throwing an exception in seeOther if the user hasn't declared a preference one way or another? Not convenient, but safe.

Not confident about the suggestion- just continuing the conversation.

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Worthington-Bodart]

Well I think the new way is safer and certainly what you would expect if you used the software for the first time. The problem is if you rely on the old behaviour. 

However your point is correct, this could break something and you would only notice in production. But if I was to talk about odds, the new way is much less likely to cause a problem while the old way you would always have to do something when reverse proxing  but you might have already done that change (so it might need adjusting)

A realistic example:

http://inside/path/foo -> http://outside/another/foo

This would need to be changed to match just the path 

"/path/foo" -> "/another/foo"

I don't want to make people have to choose when they first use the software as why would they choose the old behaviour?

Maybe so few people are using the library or are moving to http4k anyway (which I highly recommend if you are using Kotlin), that I should just do the right thing!

[Daniel Worthington-Bodart]

Okay I've pushed a small part of this change, just support X-Forwarded-Host (step 4) this is very unlikely to break anything but will help make things better straight away!