Nice to know, but did anybody implement this?

[henk_stobbe]

Hello all,

In the documentation:

https://www.dynatrace.com/support/help/platform-modules/digital-experience/web-applications/initial-...

You can read that when the host name is rewritten by a  proxy or load balancer the X-Forwarded-Host or Forwarded header can be used by oneAgent.

- I assume that the detection rule and the  of the original host/domain can be used is this correct?

- The cookie set by oneAgent will contain original host/domain tp prevent CORS issue's

- If you have original and rewritten, put the rewritten detection rule first?

Who has tested this in practice? And does this really work? It sounds like magic (-;

KR Henk

[henk_stobbe]

Hello,

It becomes a nice to know (-;

Found more info, there are options in dynatrace to use  information in "request headers" to modify the Hostname and/or IP from the source:

KR Henk

[Romanenkov_Al3x]

Hello.

---

@henk_stobbe wrote:

...

- I assume that the detection rule and the  of the original host/domain can be used is this correct?

- If you have original and rewritten, put the rewritten detection rule first?

...

---

As I understand this we need only one rule - that contains original host/domain.

If JS agent can't define application URL - in this case JS agent will try to find value in:
X-Host, X-Forwarded-Host, YOUR-TEAM-CUSTOM-HEADER

If JS agent can define without this headers - rules will work - so application detection rule for original host/domain - will work. If can't - and headers were added - again will work rule that contain original "host/domain".

We faced this when HTTP2 is using - there is no header "host" in this case.  You can check - if you will see in DevTools something like this in request headers ( :authority: )

One case was to ask Customer don't block request header origin \ request header - host. After this JS agent in our case define application URL correclty without additional headers.

Another case was to ask put correct info in X-Host, X-Forwarded-Host. Also rules works that contain original "host/domain".

Anyway for all of these cases - it will take time to troubleshoot. Also in such situations additional logs on web server helps, which can locate "client request headers", because in our case Customer team said that there is no PROBLEM on load-balancers and firewalls and REQUEST HEADERS are set by browser on client side, but when we try to check the logs on last web server in the chain - customer has gotten "many surprises".

Unfortunately, the Customer team could not do anything with it, so we created a separate environment for this application and rename Defaul RUM Application\ My Web Application. 

All such difficult cases were successfully resolved by Dynatrace Support Team. 

Big thanks to Shahin Mikayilov 😉

In these cases, I would ask the Сustomer for extended logs, all the necessary and helpful information and would ask  support for help. This could really save a lot of time.

Regards,

Alex Romanenkov

[henk_stobbe · Accepted solution]

Reading all comments, in short:

1) The browser sends a request to the server (including oneAgent)

2) Server/Onegent try to determine what domain can be found in the request.

3) A set-cookie is send back with a manually set defined domain, or the found domain in the request (rule based), or the OneAgent server domain itself.

4) This cookie domain is further  used in the session