When Traefik set x-forwarded-uri when forwarding a request, would it be a good idea that the URI is urlencoded? Its hard to use for redirecting to the x-forwarded-uri now as the URI header may contain invalid characters, for example when running graphql queries like /graphql={hello} where the curly brackets will be sent in the x-forwarded-uri as curly brackets and not url encoded. Same with other tricky characters like []^~ to name a few.
To be able to redirect to a valid url again, I need to re-encode the URI to valid urlencoded URI, but because x-forwarded-uri also contain fragments, query-parameters and path parameters, which could all contain invalid characters everything must be deconstructed into its parts, encoded and then reassembled again to create a valid url again.
Wouldn't it be better if Traefik could just let the valid, encoded url be set instead?
The incoming x-forwarded-uri is not encoded at all, it is passed raw like its received from the client.
For example a https://www.example.test/graphql?query={hello} would be received in the backend application exactly like that. I have a tomcat/jetty backend application and none of them manage to redirect to a url like that without crashing and returning 500 server error.
To be able to redirect to a url like that I need to deconstruct the whole x-forwarded-uri into its pieces, even down to each query parameter and encode the values. Which is very error prone and buggy to implement if you want to handle all kinds of outliers of invalid requests, and afterward you need to reconstruct the whole url again like a valid url.
If traefik could do the encoding it would be helpful, but when thinking about it, I don't think it would be correct of traefik to correct the clients mistakes either. Tomcat/Jetty should be able to set the status and location to redirect without crashing and let the client that sent the invalid url handle its own mistakes in best way.
This kind of problem would be present for all proxy type of applications, where the backend received a request and redirects to the x-forwarded-uri. In my case an oauth2 forwardauth backend where you have to redirect to the original url after sign in.
You hit the nail on the head here. This is exactly why a lot of the decisions we make may seem contrary to what some users would want, but "fixing" one client's mistakes can cause cascading issues with other clients, and it is a slippery slope.
The x-forwarded-uri header is an exact copy of the incoming request, unmodified for this very reason, in the event that the request is encoded by some middleware or server code, this header is pure.