IIS6, ETag, IE6 caching and serious perfomance headache

People,

Does anyone understand the constitution of the ETag generated by IIS when it
sends static content.

I've been observing a problem which I think is a bug in IE (or more
accurately Wininet) which occurs when the ETag of a resource is different
but it's Last-Modified date isn't.

Using fiddler I see a request to a server for a resource which carries
headers such as these:-

GET /aFolder/a.js HTTP/1.1
Accept: */*
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 06 Jul 2006 12:42:16 GMT
If-None-Match: "084869cf9a0c61:71e"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705; .NET CLR 1.1.4322)
Host: myhost.com
Proxy-Connection: Keep-Alive

The server responds with these headers and then the resource content:-

HTTP/1.1 200 OK
Content-Length: 18477
Content-Type: application/octet-stream
Last-Modified: Thu, 06 Jul 2006 12:42:16 GMT
Accept-Ranges: bytes
ETag: "084869cf9a0c61:729"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Fri, 01 Sep 2006 10:40:51 GMT

Note that the If-Modified-Since in the request and the Last-Modified in the
response are identical. However the ETag in the request If-None-Match
header doesn't match the responses ETag. So the servers response is correct
in this case.

Note also the first part of the ETags do match (I'm guessing that this is
some kind of hash of the content body). It is just the final part after the
colon which is different 71e is sent but the response is 729. Now I'm
guessing this has something to do with the web site sending the response
since this part of the Etag is common to all requests to the site.

Now annoyingly when another request is made for the same resource the 71e
ETag is still sent in the request dispite having just seen a response that
used a different ETag. So again the response is 200 with the new ETag which
seems to be ignored. Hence all subsequent requests for this resource that
should at least result in 304 (or shouldn't even require a trip to the
server at all) are fullfiled with 200 with the full content in the body.

Ok so that's an IE issue I know but note that this second part of the ETag
is common accross all requests to the site. Now I've had an issue with a
couple of customer sites where for some reason this final part of the ETag
has changed. This means that practically all requests for static content is
now being responded to with status 200 instead of 304 and is therefore a
major performance headache.

The current solution is to inform all users to delete temporary internet
files.

Can any one tell me what might cause a web site to start using a different
value at the end of the ETag?

I also have one or two customers wanting to use load balancing. For this
not be a problem all servers would need to send the same ETag for the
identical static content they have, how is this acheived?

TIA,

Anthony.

"Anthony Jones" <Ant RemoveThis @yadayadayada.com> wrote in message
news:euLOdubzGHA.4816@TK2MSFTNGP06.phx.gbl...
> People,
>
> Does anyone understand the constitution of the ETag generated by IIS when
it
> sends static content.
>
> I've been observing a problem which I think is a bug in IE (or more
> accurately Wininet) which occurs when the ETag of a resource is different
> but it's Last-Modified date isn't.
>
> Using fiddler I see a request to a server for a resource which carries
> headers such as these:-
>
> GET /aFolder/a.js HTTP/1.1
> Accept: */*
> Accept-Language: en-gb
> Accept-Encoding: gzip, deflate
> If-Modified-Since: Thu, 06 Jul 2006 12:42:16 GMT
> If-None-Match: "084869cf9a0c61:71e"
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
> 1.0.3705; .NET CLR 1.1.4322)
> Host: myhost.com
> Proxy-Connection: Keep-Alive
>
> The server responds with these headers and then the resource content:-
>
> HTTP/1.1 200 OK
> Content-Length: 18477
> Content-Type: application/octet-stream
> Last-Modified: Thu, 06 Jul 2006 12:42:16 GMT
> Accept-Ranges: bytes
> ETag: "084869cf9a0c61:729"
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Date: Fri, 01 Sep 2006 10:40:51 GMT
>
> Note that the If-Modified-Since in the request and the Last-Modified in
the
> response are identical. However the ETag in the request If-None-Match
> header doesn't match the responses ETag. So the servers response is
correct
> in this case.
>
> Note also the first part of the ETags do match (I'm guessing that this is
> some kind of hash of the content body). It is just the final part after
the
> colon which is different 71e is sent but the response is 729. Now I'm
> guessing this has something to do with the web site sending the response
> since this part of the Etag is common to all requests to the site.
>
> Now annoyingly when another request is made for the same resource the 71e
> ETag is still sent in the request dispite having just seen a response that
> used a different ETag. So again the response is 200 with the new ETag
which
> seems to be ignored. Hence all subsequent requests for this resource that
> should at least result in 304 (or shouldn't even require a trip to the
> server at all) are fullfiled with 200 with the full content in the body.
>
> Ok so that's an IE issue I know but note that this second part of the ETag
> is common accross all requests to the site. Now I've had an issue with a
> couple of customer sites where for some reason this final part of the ETag
> has changed. This means that practically all requests for static content
is
> now being responded to with status 200 instead of 304 and is therefore a
> major performance headache.
>
> The current solution is to inform all users to delete temporary internet
> files.
>
> Can any one tell me what might cause a web site to start using a different
> value at the end of the ETag?
>
> I also have one or two customers wanting to use load balancing. For this
> not be a problem all servers would need to send the same ETag for the
> identical static content they have, how is this acheived?
>
> TIA,
>
> Anthony.
>

Oh well I guess it is a bit of a tough one. My thanks to anyone who at
least waded through that lot and gave it some thought.

Anthony.