X-Forwarded-Proto doesn't handle multiple values

[NickCraver]

Came across this via aspnet/KestrelHttpServer#365 (comment) and I'm glad to see it in the core this round. There's a bug I see though:

• X-Forwarded-For assumes comma-separated values (OverrideHeaderMiddleware.cs#L43) (correct).
• X-Forwarded-Proto assumes a single value (OverrideHeaderMiddleware.cs#L75) (incorrect).

Both of these should support comma-separated values. For example if you have an edge node in europe that's HTTPS but then HTTP back to the origin (the load balancer adding a second entry) and then to the app, you'll get:

X-Forwarded-Proto: http, https

Or if it's HTTPS at both hops (yay security!):

X-Forwarded-Proto: https, https

While it doesn't answer the complicated question of what the app should get in complicated scenarios (this will definitely vary with such setups), it needs to not at least not break by default. I think using the 0-th entry is correct in both cases for the basic middleware use case.

[muratg]

@Tratcher Was this a miss or was it intentional?

[Tratcher]

It's a bug. I'll work on it as part of my other improvements.

[Tratcher]

44f03ef

[NickCraver]

@Tratcher I think a lot of invalid assumptions are made in 44f03ef to the point it's not actually usuable for any web traffic we see today. For example, the counts of items in each header all being equal: that certainly isn't the case in most of the traffic we see out in the wild. For example many proxies never append http to the X-Forwarded-Proto chain because it just wasn't a thing when they were created.

To be blunt, these headers are a giant mess across the internet. The code in the middleware assumes far more normalization than is actually realistic now and I'd wager at least the next 3-5 years. When HTTP/2 takes hold and all the proxies get updated or don't fool with the traffic I think sanity will gain traction...but this needs to be usable well before that.

[Tratcher]

How many proxies do you see a normal request coming through? I'd only expect you to apply settings for the reverse proxies between your server and the internet, not all the way back to the client.

If one header like X-Forwarded-Proto is out of sync with the others but you still want to apply it, and know how many entries to trust, you can have a separate instance of the middleware configured just for that header. The way things are written that shouldn't cause issues or extra overhead.