Different behaviour of set-uri after v 2.0

Hi all,

My team (devops in a large SaaS platform) stumbled on a different behaviour of ‘http-request set-uri’ after we upgraded from 2.0 to 2.8. We haven;t tried the intermediate versions so we cannot be sure when this was introduced.

We extensively use this method in our backends to route requests to an internal ALB while changing the hostname and path as needed. For standardization, we always use the full URI method.

In one case, we are routing to a backend app that uses the original request’s host header. This app stopped working after upgrading to 2.8. We then found that, while in 2.0, the request to the backend app was done with the new URI and the original host header, in 2.8 the set-uri operation also changed the host header, setting it to the URI’s host.

We verified the above with packet captures and of course I can provide more information if needed.

We applied a workaround using a custom header and solved the problem. I am only writing here because I was not able to find this change in any release notes and I thought probably other people will face it (although it may be somewhat of an edge case for many).

The behavior in 2.8 seems correct and expected.

It is not expected to maintain the original host header when you are fully rewriting the URI.

I’m assuming this was fixed in BUG/MINOR: http-htx: Don't consider an URI as normalized after a set-… · haproxy/haproxy@84cdbe4 · GitHub due to bug http-request set-uri only sets path for HTTP/2 requests · Issue #1938 · haproxy/haproxy · GitHub

1 Like

Hi Lukas,

Many thanks for your reply!

I am not claiming this is a problem. Just a change that some might be interested in.

Since we are at this point, I am looking at the changed text in the manual that reads:

If an absolute URI is set, it will be sent as is to
HTTP/1.1 servers. If it is not the desired behavior, the host, the path
and/or the query string should be set separately.
See also “http-request set-path” and “http-request set-query”

I am wondering how one may be able to set separately the host part of the URI. I only see documentation regarding the path and query parts.

With H1/H2 interworking and the HTTP version agnostic HTX mode, this will and needs to be normalized, so this is not really an option.

I would suggest you go the other way around. If a backend server needs a specific host header (that is different than the host part of the URI), manually reset the host header after the URI operation.

But frankly I don’t really understand the use case. You are saying that the backend servers needs an absolut URI with a host part that is xxxx.example.org while at the same time the backend server requires the host header to be different e.g. yyyy.example.org ?

1 Like

Hi again,

As I wrote, we have already worked-around this with a custom header so it is not really a problem for us. I understand the normalization issue with H1/H2 etc. Also, I am not claiming that this is a bug or an error etc etc. Just a different behaviour.

I just found this phrase in the manual which suggests to people to set the host separately while this, understandably, cannot be done.

Since you are asking, the use case is that we have a few services that render customized content according to the host that made the request. Those apps, were picking up the host header and since this started being normalized by the set-uri (absolute) they were picking up the internal ALB hostname that we set using the set-uri function. We are making the necessary changes in the apps to use a custom hostname so that we do not have to interfere with the proper normalization.

1 Like