ALWAYS include the `Vary: Accept-Encoding` header when response compression is enabled

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Currently, the response compression middleware only adds a Vary: Accept-Encoding header to the response, if and only if the request contains an Accept-Encoding header.

This is wrong. The Vary: Accept-Encoding header should be included in the response regardless of whether or not Accept-Encoding was part of the original request. This is because otherwise, if the very first request is one without the Accept-Encoding header (and by extension there is no Vary: Accept-Encoding in the response), an HTTP cache would not know that if a subsequent request came in that did include an Accept-Encoding header, it should NOT use the previous cache entry to satisfy that request.

The value of the Vary header shouldn’t be ‘conditional’ (for a request to the same URL). That’s incorrect behavior and would cause issues especially with proxy caches (e.g. CDNs).

This principle is something that was explicitly pointed out in this article by Fastly — which is also mentioned in the MDN page for Vary.

Expected Behavior

The Vary: Accept-Encoding header should be included in every response whose Content-Type MIME type is supported by the response compression middleware, regardless of the presence of Accept-Encoding in the request.

This same principle also applies to any middleware that might add a value to the Vary header of the response, there could be some others in the ASP.NET Core codebase as well, although the response compression middleware is the one I stumbled into.

The relevant piece of code seems to be the following: https://github.com/dotnet/aspnetcore/blob/86817b0c9fbb9b730bf3ce63da34b75570ee5696/src/Middleware/ResponseCompression/src/ResponseCompressionBody.cs#L202-L225

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[adityamandaleeka]

Thanks for reporting this @aradalvand, I just looked at this and you’re right that this is a bug.

It looks like we bail in invoking the middleware entirely if the Accept-Encoding header is not set in the request.

https://github.com/dotnet/aspnetcore/blob/f56c242d037e7a11626151e78333caa26c3b5d00/src/Middleware/ResponseCompression/src/ResponseCompressionMiddleware.cs#L37-L45

https://github.com/dotnet/aspnetcore/blob/f56c242d037e7a11626151e78333caa26c3b5d00/src/Middleware/ResponseCompression/src/ResponseCompressionProvider.cs#L219-L229

We’ll need to fix this logic so that the Vary: Accept-Encoding header is included regardless.

[Tratcher]

That label just means it’s part of a middleware feature area, response compression.