IE and its poor HTTP support

[mmj]

I'm implementing conditional GET in my application, and I've discovered a number of bugs in Internet Explorer (version 6)'s HTTP implementation as follows:

When using gzip Content-Encoding at the same time as Cache-Control or Expires, Internet Explorer ignores any caching directives and always returns a cached result even when stale.
See here http://support.microsoft.com/default...b;en-us;321722


Also, when using gzip Content-Encoding, Internet Explorer will "forget" the etag, so it can't use If-None-Match.

Also, when using a caching control mechanism such as "Vary", Internet Explorer will "forget" the etag, so it can't use If-None-Match.

What does this mean?

This means it is impossible to implement caching and conditional get properly in a dynamic webpage.

This also means it is impossible to implement gzip encoding and conditional get and have it work in Internet Explorer.

My point: Internet Explorer still has very limited support for caching, conditional get, and content-encoding, so much so that you can never depend on using more than one at the same time. For a developer like me, it means I have to choose what is more important: conditional get with no gzip or cache control, cache control with no gzip or conditional get, or gzip content-encoding but no caching or conditional get.

What can I do?

Can anyone show me an implementation that uses more than one of these and still works?

[cfm]

Off Topic:


Not terribly helpful, I know, but shouldn't this thread be called "IE and it's poor Web support?" No, I know that you're focusing on the conditional get, but I just had to open my mouth.

[Daijoubu]

Huh, I've implemented caching with PHP via ETag without a problem (well, except Opera7...works in Moz/FF[FB])
IE simply doesn't support caching of any GZIP'ed content

The Vary: bug from IE4 seems to be still here..

[mmj]

Yes, this will work if you have caching and conditional gets with the Etag, but without any "Vary" header.

If you have a "Vary" header, it breaks. The "Vary" header is necessary with a dynamic page, where the content of the page may be different according to other factors other than modification time such as whether somebody is logged in, etc.

I have implemented the following logic:

check for accept-encoding and use gzip encoding if valid
send header Content-Encoding if using gzip encoding

send header Etag
send header Last-Modified if there's no vary
send header Vary if there is vary
send header Cache-Control unless using IE and using gzip
send header Expires unless using IE and using gzip

check for if-none-match and halt with 304 on match
check for if-modified-since and halt with 304 on match and there wasn't an if-none-match

[Daijoubu]

Why do you need to use the Vary header? What is it for? (Yes, I know I could read the RFC, but heh )

I would do (like megaman):

Check presence of IF_NONE_MATCH, send 304 and exit if match found
Check User-Agent, if it's not IE, start GZIP, else, strip tabs/newlines to save some bandwidth
Send ETag
Send content

Here's a little example of "working" cache (except in Opera...)
http://ptprophecy.com/tests/cache_test.php
No GZIP though

[mmj]

The Vary header specifies that the page returned for the same URL may be different according to other factors. It is required for caches including proxy caches and browser caches to ensure that the correct version of a page is always returned.

For instance, if your page might vary based on the contents of somebody's cookies, then you should use "Vary: Cookie" to ensure that the page from the cache is only valid for a request containing the same cookies. If your page might vary based on the user's User-Agent string, you should have "Vary: User-Agent". If the page might vary depending on outside factors not present in the request, you should use "Vary: *", although in reality this means that nothing could be cached.

Pretty much all dynamically generated pages should send a "Vary" of some sort, indicating that the content at the same URL might vary. It is necessary for proper caching of dynamic pages. If you don't use Vary, a cache might return the wrong version of the same page at a later time.

Browser cache support for the Vary header is limited, but proxy caches seem to support it better, because with a proxy cache it is more important not to send the wrong version of a page to a user. While no browser implements it fully, the only browser that actually breaks the standard is Internet Explorer, which ignores the Vary header (and any other cache header including Cache-Control and Expires) when using gzipped content.

[mmj]

Originally Posted by Daijoubu

http://ptprophecy.com/tests/cache_test.php

This page does not send any cache control headers, so all browsers and all proxy caches will always need to revalidate the page with the origin server to determine if the page has changed. That is, the cache can never return the page without checking with the origin server. Not sending any cache control headers will be interpreted just like "Vary: *" or "Cache-Control: must-revalidate" by most browsers and caches.

If the page hasn't changed, the origin server will return a "304 Not Modified" status without a body.

Apart from the possible bandwidth saving, this doesn't save any significant server load, because the server still needs to execute the script on each view. Even then, if the page is gzipped, then Internet Explorer won't send any "If-None-Match" so the etags become useless.