Tunnel adds unnecessary response headers

[gerneio]

When using dev tunnels, various unnecessary headers are added to the response which are NOT set by the underlying application. Matter of fact, attempting to set one of these response headers from the downstream app will result in the dev tunnel proxy overriding it. In some cases, this causes a difference in behavior when running behind a tunnel vs in local dev vs in prod.

Example (routing to '/' which in this case should lead to a 404 w/ no content):

Tunnel Response Headers (after Consent Page has already been shown):

cache-control: no-cache,no-store
content-length: 0    
date: Fri, 17 Jan 2025 17:02:17 GMT
expires: Thu, 01 Jan 1970 00:00:00 GMT
pragma: no-cache
ratelimit-limit: HttpRequestRatePerPort:1500/m
ratelimit-remaining: HttpRequestRatePerPort:1499
ratelimit-reset: HttpRequestRatePerPort:28s
referrer-policy: same-origin
set-cookie: .Tunnels.Relay.WebForwarding.Cookies={REDACTED}; path=/; secure; samesite=none
strict-transport-security: max-age=31536000; includeSubDomains
vssaas-request-id: {REDACTED}
x-content-type-options: nosniff
x-ms-ratelimit-limit: 1500
x-ms-ratelimit-remaining: 1498
x-ms-ratelimit-reset: 0
x-ms-ratelimit-used: 2
x-report-abuse: https://msrc.microsoft.com/report/abuse
x-robots-tag: noindex, nofollow
x-served-by: tunnels-prod-rel-usw3-v3-cluster

W/o Tunnel:

content-length: 0
date: Fri, 17 Jan 2025 17:06:44 GMT
server: Kestrel

As you can see, the tunnel adds TONS of response headers. The main one causing me a headache right now is the referrer-policy one, which wont let me override it, causing a diff in behavior between local dev and tunnel dev. However, many of these other response headers probably shouldn't be present either. It's probably easier to say which response headers the proxy should be ok to set:

set-cookie: .Tunnels.Relay.WebForwarding.Cookies=
strict-transport-security
vssaas-request-id
x-report-abuse
x-robots-tag
x-served-by

The rate limiting ones are probably ok as well, just as long as there are no conflicts with the default ones typically provided by an asp core app w/ rate limiting middleware (not 100% what they default to).

I would imagine some of these might be set for that default consent page, and that is ok when actually producing the consent page, but not for ALL routes.

At minimum, if I specify certain response headers within my downstream app, the tunnel proxy should respect it and NOT override it. We need more control over our response headers!