304 reponse with unrecognised ETag

Hi

I'm seeing a few problem sites, where the server replies with a 304 to a 
conditional request, but the ETag doesn't match any known ETag.  E.g 
from a packet capture:

GET /economics/charts/nzdusd_1_hourly.gif HTTP/1.1
Host: www.nationalbank.co.nz
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.31 Safari/530.5
Referer: http://www.nationalbank.co.nz/economics/exchange/nzdusd.aspx
Accept: */*
Accept-Encoding: gzip,deflate,bzip2,sdch
Cookie: s_vi=[CS]v1|499E6E6A00006868-A0208AF00000004[CE]; 
s_nr=1244358115085; s_cc=true; s_sq=%5B%5BB%5D%5D
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
If-Modified-Since: Fri, 19 Jun 2009 10:19:38 GMT
If-None-Match: "8042c973c7f0c91:64e6"
Connection: Keep-Alive

HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/5.0
Date: Fri, 19 Jun 2009 10:27:31 GMT
X-Powered-By: ASP.NET
Cache-Control: no-cache
Expires: Fri, 19 Jun 2009 10:27:31 GMT
ETag: "08de660c7f0c91:6a9f"
Content-Length: 0


Apart from the known IIS bug with Content-Length: 0, how is an 
intermediary cache to deal with this?

Is it allowable to change an ETag on a stored representation?  Isn't the 
whole point of an ETag that it uniquely identifies a rep, and so a 
different ETag means a different representation?

The 304 is pretty clear, whatever the client asked for hasn't changed.  
But what if there were more than one ETag in the request?  Which stored 
representation would one update?  the latest?

Does this mean it's generally a really bad idea to have more than 1 Etag 
in a If-None-Match header, or at least more than 1 added by an 
intermediary cache?  IOW is it a really bad idea for an intermediary to 
try and use If-None-Match to see which stored representation is the one 
that's still valid?

In terms of the spec, it says you must always serve the stored rep with 
the latest Date header, but what about for revalidation?

Thanks

Adrien



-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Friday, 19 June 2009 10:35:47 UTC