Kernel-Mode caching does not support VaryByHeaders in IIS 10

Question

Kernel-Mode caching does not support VaryByHeaders in IIS 10

Aishwarya Rajan 0

Hi,

I have a use case, where some js files are enabled for kernelCaching. The files are getting cached correctly, but when the file is retrieved there is a mismatch due to encoding of the file.
For eg:

When I enable only gzip compression, gzip compressed file is returned.

When I enable only brotli compression, brotli compressed file is returned.

When I enable both gzip and brotli compression, because brotli is of higher priority in my list, brotli compressed file should be returned, however gzip compressed file is returned. And this behaviour is inconsistent, sometimes gzip compressed file is returned, sometimes brotli compressed file is returned.

On reading some articles, I found that we can add this option of varyByHeaders to return files based on headers. However, that is available on User-Mode caching only and not on Kernel-Mode caching.

as per the screenshot below.

Is VaryByHeaders supported for kernel-caching?

If yes, how to enable it?

If no, how to vary the files based on encoding when kernel cache is enabled? (Disabling it will cause performance impact in my case.)

User's image

Lex Li (Microsoft) 6,022 Reputation points Microsoft Employee

2023-02-16T05:12:58.9433333+00:00

"And this behaviour is inconsistent, sometimes gzip compressed file is returned, sometimes brotli compressed file is returned" is what you should dig into further via tools like FRT, as documented in this article. The IIS compression behaviors might be triggered by incoming HTTP requests, which you neglected early on.

Only when you know for sure the change in compression algorithm is not caused by HTTP requests, but IIS itself, you can start to find solutions. Otherwise, any guess (like assuming VaryByHeaders might help) can take you to the wrong path.
Aishwarya Rajan 0 Reputation points

2023-02-17T06:57:45.8733333+00:00

Hi Lex,

I took FRT logs again today and did some anlaysis on it. I found one thing interesting.

I have enabled both gzip and br compression.
For network calls, the request headers has Accept-Encoding: gzip, br, and the response headers have Content-Encoding: br. This is expected.

But for js and css files, the request headers has Accept-Encoding: gzip and the response headers have Content-Encoding: gzip. However, both encodings are enabled and in the chrome developer tools request headers shows Accept-Encoding: gzip, br.

So, from the browser when the request is sent, it has both gzip and br, when in the FRT logs, the encoding is coming as gzip only. Because it has gzip only, it returns gzip file only. Ideally it should also have gzip and br encoding in the request headers like other network calls.

2 answers

Your answer

Lex Li (Microsoft) 6,022 Reputation points Microsoft Employee

2023-02-16T05:12:58.9433333+00:00

"And this behaviour is inconsistent, sometimes gzip compressed file is returned, sometimes brotli compressed file is returned" is what you should dig into further via tools like FRT, as documented in this article. The IIS compression behaviors might be triggered by incoming HTTP requests, which you neglected early on.

Only when you know for sure the change in compression algorithm is not caused by HTTP requests, but IIS itself, you can start to find solutions. Otherwise, any guess (like assuming VaryByHeaders might help) can take you to the wrong path.
Aishwarya Rajan 0 Reputation points

2023-02-17T06:57:45.8733333+00:00

Hi Lex,

I took FRT logs again today and did some anlaysis on it. I found one thing interesting.

I have enabled both gzip and br compression.
For network calls, the request headers has Accept-Encoding: gzip, br, and the response headers have Content-Encoding: br. This is expected.

But for js and css files, the request headers has Accept-Encoding: gzip and the response headers have Content-Encoding: gzip. However, both encodings are enabled and in the chrome developer tools request headers shows Accept-Encoding: gzip, br.

So, from the browser when the request is sent, it has both gzip and br, when in the FRT logs, the encoding is coming as gzip only. Because it has gzip only, it returns gzip file only. Ideally it should also have gzip and br encoding in the request headers like other network calls.

Answer 1

Sam Wu-MSFT 7,556 Microsoft External Staff

@Aishwarya Rajan

The kernel-mode output cache supports the varyByHeaders attribute, but not varyByQuerystring.

Select a Cache Policies

varyByHeaders specifies a semicolon-separated list of HTTP headers used to vary the output cache. When this attribute is set to multiple headers, the output cache contains a different version of the requested document for each combination of specified headers. you can try to set it in the profiles property.

More information you can refer to this link: Configuration Sample.

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Aishwarya Rajan 0 Reputation points

2023-02-14T05:14:16.92+00:00

Hi @Sam Wu-MSFT

According to the documentation, Kernel mode caching says it supports varybyheaders, however, it does not. If could look at the screen shot I have pasted above, User-mode caching has advanced settings option, through which we can set up varyByHeaders and varyByQueryString attributes, however, kernel-mode caching does not have advanced settings to set either of the values.

Also, I have tried the configuration sample link that you have pasted above. That works only in case of user-mode caching and not kernel-mode caching.

Please could you relook into this issue and provide a solution for my use-case.
Thanks.
Sam Wu-MSFT 7,556 Reputation points Microsoft External Staff

2023-02-15T09:03:19.64+00:00

@Aishwarya Rajan

Some properties in iis are not necessarily displayed on the ui.

Please post your test content and results in kernel-mode caching.
Aishwarya Rajan 0 Reputation points

2023-02-16T05:02:08.01+00:00

Hi @Sam Wu-MSFT

Like you said in IIS we cannot set the varyByHeaders for kernel cache. I have added this configuration is my web.config file for aspnet mvc application.

I have enabled gzip and brotli compression for IIS.

When I access my application, it does some network calls to backend, it loads some js and css files at various points.
When I enable only br encoding through google chrome developer tools, all calls have br encoding in the response headers. Kernel cache has the br compressed files. (I use this command to view the files in kernel cache : netsh http show cachestate)

When I enable only gzip encoding through google chrome developer tools, all calls have gzip encoding in the response headers. Kernel cache has gzip compressed files.

When I enable both gzip and br encoding, all network calls have br encoding, but js and css calls have gzip encdoing in the response headers. Because br is my browser default, all calls should have br encoding and given that kernel cache also has br compressed files, js and css files also should come with br encoding, but I get gzip compressed files.

So, I am facing issue when both gzip and br encoding is enabled, the files are not returned as per varyByHeaders attribute.
Sam Wu-MSFT 7,556 Reputation points Microsoft External Staff

2023-02-16T09:02:16.17+00:00

@Aishwarya Rajan

Please check if you have dynamic content compression enabled in iis, if dynamic content compression is enabled, the Vary header is overwritten as "Accept-Encoding".
Aishwarya Rajan 0 Reputation points

2023-02-16T12:25:17.3566667+00:00

@Sam Wu-MSFT
Dynamic compression is enabled in IIS. I have pasted the screenshot of it which tells what all types are compressed. Please have a look in the above comment.
Aishwarya Rajan 0 Reputation points

2023-02-16T12:26:45.8433333+00:00

Hi @Sam Wu-MSFT

Dynamic compression is enabled in IIS. I have pasted the screenshot of it in the above comment. Please have a look, it tells what types are compressed also.
Aishwarya Rajan 0 Reputation points

2023-02-17T06:58:25.4233333+00:00

Hi @Sam Wu-MSFT

I took FRT logs again today and did some anlaysis on it. I found one thing interesting.

I have enabled both gzip and br compression.
For network calls, the request headers has Accept-Encoding: gzip, br, and the response headers have Content-Encoding: br. This is expected.

But for js and css files, the request headers has Accept-Encoding: gzip and the response headers have Content-Encoding: gzip. However, both encodings are enabled and in the chrome developer tools request headers shows Accept-Encoding: gzip, br.

So, from the browser when the request is sent, it has both gzip and br, when in the FRT logs, the encoding is coming as gzip only. Because it has gzip only, it returns gzip file only. Ideally it should also have gzip and br encoding in the request headers like other network calls.

Answer 2

Lex Li (Microsoft) 6,022 Microsoft Employee

Deleted deleted.

Aishwarya Rajan 0 Reputation points

2023-02-16T05:24:34.99+00:00

Hi Lex,

Could please explain your comment.
Lex Li (Microsoft) 6,022 Reputation points Microsoft Employee

2023-02-16T05:33:35.4066667+00:00

I just tried to remind you that there is a very big gap between "this behaviour is inconsistent, sometimes gzip compressed file is returned, sometimes brotli compressed file is returned" and "I found that we can add this option of varyByHeaders to return files based on headers". More investigation is needed to reveal the actual cause of the inconsistency, or you can find a wrong way there. Without solid evidence like FRT logs, I don't think anyone can quickly jump to a solution.
Aishwarya Rajan 0 Reputation points

2023-02-16T06:55:58.3733333+00:00

If could look at the above comments that I have added with all my configurations, probably you'll get an idea of what is my use case.
The reason that it is inconsistent is after sometime, cache file expires and gets deleted. Then whatever is remaining in the kernel cache is will be returned, though it is not expected.

In my above comment, I have mentioned that when both gzip and br encoding is enabled and when both the compressed files exist in the kernelcache, even if I add varyByHeaders attribute, it does not return the expected file with the right encoding. This is my use-case.

I took the FRT logs in my machine, but did not find any details regarding this issue.
Please let me know if it clarifies your question.
Lex Li (Microsoft) 6,022 Reputation points Microsoft Employee

2023-02-16T10:16:46.31+00:00

"The reason that it is inconsistent is after sometime, cache file expires and gets deleted. Then whatever is remaining in the kernel cache is will be returned, though it is not expected." Again, that's an assumption without concrete evidence support. The timing you captured FRT logs is also important, when you claim the inconsistency only happens "after sometime". You might already analyze a lot so far and shared some information, but incomplete data are less helpful when the discussion goes deep.

You might open a support case via https://support.microsoft.com and through that all the data can be analyzed again. I believe by extracting the hints and rebuilding the scenes (tons of requests, the actual compression module behaviors, items in caches, the responses, and timestamps), the cause will be revealed.
Aishwarya Rajan 0 Reputation points

2023-02-17T06:59:33.32+00:00

Hi Lex,

I took FRT logs again today and did some anlaysis on it. I found one thing interesting.

I have enabled both gzip and br compression.
For network calls, the request headers has Accept-Encoding: gzip, br, and the response headers have Content-Encoding: br. This is expected.

But for js and css files, the request headers has Accept-Encoding: gzip and the response headers have Content-Encoding: gzip. However, both encodings are enabled and in the chrome developer tools request headers shows Accept-Encoding: gzip, br.

So, from the browser when the request is sent, it has both gzip and br, when in the FRT logs, the encoding is coming as gzip only. Because it has gzip only, it returns gzip file only. Ideally it should also have gzip and br encoding in the request headers like other network calls.
Lex Li (Microsoft) 6,022 Reputation points Microsoft Employee

2023-02-18T01:46:29.6+00:00

Yes. That's an interesting finding and seems to explain the response inconsistency. But if you want to trace down why the Accept-Encoding header varies in different HTTP requests, you need more captures between the browsers and IIS.

Do you have any network devices or reverse proxies configured in between? They might manipulate the headers unintentionally.
Aishwarya Rajan 0 Reputation points

2023-02-20T05:28:47.04+00:00

Hi Lex,

There are network devices or proxies in between for me. I have hosted the application in a website in my local IIS, that's it.
Is there any way to find out why Accept-Encoding header various in different HTTP requests?
Aishwarya Rajan 0 Reputation points

2023-02-20T05:30:47.64+00:00

There are NO proxies or network devices is what I meant, simple website in local IIS

Share via

Kernel-Mode caching does not support VaryByHeaders in IIS 10

2 answers

Your answer