Haproxy: feature: url_enc function similar to url_dec

[KlavsKlavsen]

since https://github.com/haproxy/haproxy/issues/425 was closed - I'll open this with hopefully a better usecase for you :)

We require JWT login for multiple services - also several which actually does not support it - so we decode the JWT in haproxy (lua) to verify it, before even forwarding the request. All this works great.
But - if the visitor does not have a valid JWT (or its too old) - we'd today redirect them to the login page (on a diff. central domain) - and we'd really like to pass along the url they were trying to visit, so they can be redirected back by after login.

That requires us to take the url and url enc it in the Location we're sending.. haproxy needs this function to do that.

[wdauchy]

I will try to have a closer look in the following weeks

[wdauchy]

since #425 was closed - I'll open this with hopefully a better usecase for you :)

We require JWT login for multiple services - also several which actually does not support it - so we decode the JWT in haproxy (lua) to verify it, before even forwarding the request. All this works great.
But - if the visitor does not have a valid JWT (or its too old) - we'd today redirect them to the login page (on a diff. central domain) - and we'd really like to pass along the url they were trying to visit, so they can be redirected back by after login.

That requires us to take the url and url enc it in the Location we're sending.. haproxy needs this function to do that.

so if I understand correctly when a user comes with:
http://foo.com/bar?toto=42
and it triggers the login error, you want to be able to redirect to such URL:
http://foo-login.com/?url=http%3A%2F%2Ffoo.com%2Fbar%3Ftoto%3D42
so a url_enc converter would return a fully encoded string of the url.

Is that correct?

Also @wtarreau, could you advise whether this would be acceptable?

[wtarreau]

I'm all in favor for an url_enc converter to match url_dec. However, we must be careful not to reproduce the mistakes of the past. URL encoding doesn't work the same depending where it's used, and for this we need to support an argument to the converter to indicate which type of encoding is needed. Above what I understand is that the purpose is to encode for a query string parameter value. I don't see other use cases of encoding for use in the query string, as it wouldn't make sense to pass a non-normalized query string and try to normalize it, so I think it should be safe to admit that we have a type of encoding for query-string. There can be other encodings, namely for the path component, where spaces are encoded as %20 instead of "+", where the ":" must be encoded as %3A and a few other things. This one would be used when assembling URLs by concatenating an authority with a path name taken from a map for example.

Please take some time to closely inspect RFC3986 and its updates to make sure that all relevant characters are encoded, and only them. and please check that our url_dec properly decodes the output of url_enc for various patterns (and even better, that url_enc,url_dec,url_enc is always the same as url_enc). Please also check if url-encoded arguments passed in POST bodies always use the exact same encoding or not, as some might possibly want to support this (for health checks I guess).

Ah another point is to quickly check if the output of an url-encoded string is always compatible with a cookie value syntax. I think it is. Because if that's the case, that's something useful there as well, and it could be mentioned in the doc that it's also a safe way to encode an opaque value in a cookie (e.g. auth token).

I'm perfectly fine if the type of encoding specified in the argument is optional and defaults to query, but I want it to be configurable (even if as a first step only query is supported), so that when a different one is needed, it's much easier for a newcomer to add support for it. I'm fine with any initial limitation as long as they are identified and documented.

Thanks for working on this one, I agree we really need it and that it's been missing for a while!

[wtarreau]

This reminded me an old discussion around this subject, more specifically about normalization, but that can be useful to fuel your design ideas, it's here: https://www.mail-archive.com/[email protected]/msg37732.html