Wrong Http Headers on responses

[vitasystems]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hello,

Just to summarize there is more than one issue(ASPNET CORE in NET 9):

1 Duplicate Accept-Range which is not a multiple value header therefore should appear only once in a response according to this RFC https://datatracker.ietf.org/doc/html/rfc7233#section-2.3

2 Vary header is set to Content-Encoding which might be good for proxies but browsers expect Vary: Accept-Encoding.
Furthermore the Content-Encoding is the header that must be set by the party that applied the encoding in this case clearly the server https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.2.2.

This contradicts the use of the Vary header which is a list of client headers that affected the decision making of the server.
https://datatracker.ietf.org/doc/html/rfc9110#field.vary

The RFC clearly states that it should contain "what parts of a request message"....

This clearly means that the correct header in the Vary response from the server is Accept-Encoding and NOT Content-Encoding.
This is because the client did NOT send Content-Ecoding...it sends Accept-Encoding. So using the Vary with a server response headers is not correct.

There was similar issue filed in June 2024 however this was for the Preview version of NET 9 and the issue does not include the Vary headers.

Here is a screenshot of the problems:

Expected Behavior

The right http headers are sent in the response:

1- Only one Accept-Ranges header per response

2- Only request headers as the value of the Vary header as stated in the mentioned RFCs: Vary: Accept-Encoding (or other client set headers in comma separated list. Not server reponse headers like "Content-Encoding")

Steps To Reproduce

1 Create a project using the latest MVC template.

2 Make sure it uses app.MapStaticAssets();

3 Run the project and inspect the Browser developer tools

Exceptions (if any)

No response

.NET Version

9.0.102

Anything else?

Visual Studio 2022 17.12.4
Workload version: 9.0.100-manifests.693890c1

[gunnarbeutner]

Also, once the Vary: Content-Encoding bug is fixed, Vary: Accept-Encoding should also be sent for responses where the client did not request a different content encoding type but where other content encodings are available. Otherwise the following can happen:

1. Client requests a resource (via a cache) without Accept-Encoding or with unsupported content encoding types.
2. Server responds with the uncompressed resource - which currently does not have a Vary: Accept-Encoding header.
3. The intermediary cache stores the uncompressed response.
4. Another client requests the same resource but specifies an Accept-Encoding type that would be supported by the upstream server.
5. The cache responds with the uncompressed data because the missing Vary: Accept-Encoding header incorrectly implies that there are no other content encoding types available.

In that case the request won't fail but all future clients won't be getting compressed responses until the cache entry expires and by chance the first few clients request compressed encoding types until the cache has been re-populated with all supported compressed encoding types.

However, currently, i.e. with Vary: Content-Encoding the case is even worse. An intermediary cache might end up sending unsupported encoding types to clients:

(base) ✔ ~
23:45 $ curl --compressed -v -o /dev/null http://localhost:8080/_framework/dotnet.native.ylx55wmvq1.js
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET /_framework/dotnet.native.ylx55wmvq1.js HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.7.1
> Accept: */*
> Accept-Encoding: deflate, gzip
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.27.4
< Date: Fri, 21 Mar 2025 22:45:34 GMT
< Content-Type: text/javascript
< Content-Length: 34818
< Connection: keep-alive
< Cache-Control: max-age=31536000, immutable
< Content-Encoding: gzip
< ETag: "T12pFt1Dptk9L4gsKMHkUIdXdZnnME7vJRxkjAt+ZbQ="
< Last-Modified: Fri, 21 Mar 2025 22:43:36 GMT
< Vary: Content-Encoding
< Blazor-Environment: Production
< X-Proxy-Cache: MISS
< Accept-Ranges: bytes
<
{ [13032 bytes data]
100 34818  100 34818    0     0  7964k      0 --:--:-- --:--:-- --:--:-- 8500k
* Connection #0 to host localhost left intact
(base) ✔ ~
23:45 $ curl -v -o /dev/null http://localhost:8080/_framework/dotnet.native.ylx55wmvq1.js
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET /_framework/dotnet.native.ylx55wmvq1.js HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.27.4
< Date: Fri, 21 Mar 2025 22:45:39 GMT
< Content-Type: text/javascript
< Content-Length: 34818
< Connection: keep-alive
< Cache-Control: max-age=31536000, immutable
< Content-Encoding: gzip
< ETag: "T12pFt1Dptk9L4gsKMHkUIdXdZnnME7vJRxkjAt+ZbQ="
< Last-Modified: Fri, 21 Mar 2025 22:43:36 GMT
< Vary: Content-Encoding
< Blazor-Environment: Production
< X-Proxy-Cache: HIT
< Accept-Ranges: bytes
<
{ [13032 bytes data]
100 34818  100 34818    0     0  18.2M      0 --:--:-- --:--:-- --:--:-- 33.2M
* Connection #0 to host localhost left intact

Note how the second curl request gets a compressed response even though there's no "Accept-Encoding: gzip" request header.