How to avoid IIS from overwriting some HTTP Headers

asp.net-mvccompressionhttpiis-7iis-7.5

I have enabled in my Web.config the GZIP compression, and I'm glad that it automatically adds the HTTP header "Vary: Accept-Encoding".

The problem is that IIS is overwriting the "Vary:*" that ASP.NET returns by default.

The issue is that in POST calls, the "Vary" header has to be "*", because it means the response depends on things that are not in the URL or the HTTP headers… as far as I know. A POST call with a "Vary:Accept-Encoding" could be wrongly cached, am I right?

What I want to do is tell IIS to respect the previous "Vary" header if any.

Regards.

Best Answer

A POST request should never be cached unless it's explicitly allowed to be by either a Cache-Control or Expires header in the response. The Vary header can be used by a proxy server to optimize the decision if it can return a cached response but that's only if the response was allowed to be cached in the first place. So if you make sure the response of your POST request is not allowed to be cached, the Vary header will/should not make it cacheable whatever it is set to.

Related Solutions

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Ok, I think we've figured it out...

On the client side, Squid 2.5 and earlier doesn't understand "Transfer-encoding: chunked", so it delivers each chunk as the entire client request. Since it's only 1 chunk of the entire compressed request, it's invalid data and can't be read by the browser. (Not sure if this is an issue with other proxies)

On the server side, IIS always sends chunked encoding for Dynamic Compression (since IIS doesn't cache application responses, it has to compress each response on the fly, hence the chunked encoding).

The only way we can think of to fix this is to completely disable compression for HTTP 1.0 clients and only compress for HTTP 1.1 responses. The drawback is that anyone behind a proxy that sends 1.0 requests won't get compressed data and the site will load 0.5 - 1 second slower for those users.

Changes made in the metabase.xml file:

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

If anyone has a better solution, please let me know!

Getting HTTP Compression (GZip) to work with URL Routing on IIS 6

Make your ASP.NET application gzip its output itself with a method like this one.

Best Answer

Related Solutions

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Getting HTTP Compression (GZip) to work with URL Routing on IIS 6

Related Topic