FR: serve: Add the X-Forwarded-Proto header

[Zaba]

What are you trying to do?

I've tried to use tailscale serve to simplify my setup since I don't have any complex reverse proxying requirements, however I found that my backend really wants to have the X-Forwarded-Proto header set to https if the proxy terminated TLS on its behalf.

How should we solve this?

Since the Tailscale server knows whether it had terminated TLS, it seems like it should be fairly easy for it to insert the X-Forwarded-Proto header with the appropriate value when reverse-proxying the requests.

What is the impact of not solving this?

Some picky backends want to see the X-Forwarded-Proto: https header and will display warnings, etc., if it's missing.

Anything else?

No response

[Zaba]

I think this may be fairly simple to fix by adding a Rewrite hook that calls SetXForwarded to the ReverseProxy somewhere in https://github.com/tailscale/tailscale/blob/main/ipn/ipnlocal/serve.go#L436. Not sure if that will handle X-Forwarded-Proto correctly without any other changes though.

[DentonGentry]

I believe this was fixed two weeks ago in 3177cca

[jamesez]

I see X-Forwarded-For but not X-Forwarded-Proto in that commit. I don't see -Proto in the source for serve.go at all; can you re-open?

@DentonGentry

[jamesez]

A use-case for this feature is when testing OIDC authentication to a Rails application. Rails (in particular) can be fussy about whether it believes its on https or not and will redirect to https if it's not, and OIDC providers often won't let you have a redirection URL that is non-SSL if it's not 'localhost'.

Thank you!

[Multiply]

We could also use this option specifically for X-Forwarded-Proto but X-Forwarded-Host would also be a nice addition

[iandees]

As another usecase for this, the Flask Python web framework (really I think Werkzeug under the covers?) uses this header to decide how to build URLs when using url_for(..., _external=True).

[zofrex]

We could also use this option specifically for X-Forwarded-Proto but X-Forwarded-Host would also be a nice addition

@Multiply could you expand a little on why X-Forwarded-Host would be a useful addition for you? My understanding is that this is only needed when a proxy rewrites the original Host header, which we aren't doing — the contents of the X-Forwarded-Host header would be the same as the Host header — but if there's a use-case for this we can look into it.

[Multiply]

We could also use this option specifically for X-Forwarded-Proto but X-Forwarded-Host would also be a nice addition

@Multiply could you expand a little on why X-Forwarded-Host would be a useful addition for you? My understanding is that this is only needed when a proxy rewrites the original Host header, which we aren't doing — the contents of the X-Forwarded-Host header would be the same as the Host header — but if there's a use-case for this we can look into it.

I'd assume it'd include the port, if it's not 80 for http, or 443 for https, so we that way can properly generate the 'correct' URLs, no matter how many layers of proxies one have, and for all supported ports.

Edit: I might have to read up on "standards", but X-Forwarded-Port also seems like an option, but I've seen most support for X-Forwarded-Host simply copying the Host header.

[mKeRix]

I also ran into this issue for a use case that I've been working on and ended up providing a PR that implements both the X-Forwarded-Host and X-Forwarded-Proto header: #8224.