Request object should provide original url after url re-writing

[mshustov]

Kibana Platform allows plugins to rewrite URL with onPreRouting interceptor.

kibana/src/core/server/http/lifecycle/on_pre_routing.ts

Line 50 in 0ea414c

rewriteUrl(url: string): OnPreRoutingResult {

There is no way to get the original url at the moment. The platform should support this case - otherwise, plugins have to implement error-prone workarounds #74640 (comment)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mshustov]

@thomheymann I didn't find hapi provides this information. Before adding this on the platform level, I want to clarify a couple of questions:

• What if we pass an original URL via a request header?
  What part of url do you need? only pathname, I suppose? would it suffices x-kibana-rewritten-pathname: /s/space_name/.... Should you need to access other url parts (port, host, etc.), we can add them as x-kibana-rewritten-port, etc. similarly to the same manner as h2o2 provides the original address

  'x-forwarded-for': '127.0.0.1',
  'x-forwarded-port': '60666',
  'x-forwarded-proto': 'http',
  'x-forwarded-host': 'localhost:5601',

• an incoming request url can be rewritten several times. Do you need an original pathname, I suppose? So the header shouldn't be overridden if presents.

[thomheymann]

I don't know for sure what the platform APIs allow you to rewrite but if plugin developers can only change the pathname, then that is all I need to get the original url. Do the query params stay intact if a plugin rewrites the pathname?

I get that adding a headers is a good approach if an external system does the url rewriting but think that if it's Kibana itself I'd prefer if that would be exposed on the url/request object itself. You've got much more context though so happy to go with your suggestion.

[mshustov]

if plugin developers can only change the pathname, then that is all I need to get the original url

No, a plugin passes the final URL, therefore, it might change any part of it, including query. originalUrl-like property should be a serialized URL object then.

I get that adding a headers is a good approach if an external system does the url rewriting but think that if it's Kibana itself I'd prefer if that would be exposed on the url/request object itself. Ok, it might be better to

I don't want to add a custom property to URL object. Adding to KibanaRequest object sounds acceptable.