W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2003

Re: Problems with caching header values

From: Robert Olofsson <robo@khelekore.org>
Date: Sat, 23 Aug 2003 20:06:04 +0200
Message-ID: <3F47AD0C.5080405@khelekore.org>
To: Wilfred Nilsen <wilfred.nilsen@cox.net>
Cc: ietf-http-wg@w3.org

Wilfred Nilsen wrote:

>The page contains links to images that never change so in order to
>prevent the browser from attempting to fetch new versions of the
>images, I set the header value "Cache-Control: max-age=86400". The
>problem is that the browsers I have tested this with, IE 6.0 and
>Mozilla 1.13, seems to ignore the max-age header value and are always
>checking for newer versions. The browsers are set to get a new page
>when the current page is out of date.
For IE have you enabled the HTTP/1.1 extensions?
(I guess that you have, but check it please).

For Mozilla I think that you should try the 1.4 release since that is
stable version for now.
Have you checked bugzilla.mozilla.org for bugs in mozilla regarding

How big are the images?
How big cache do you have?
Depending on the two above questions the image may be deleted from the
cache directly if the image is too big. I have not studied the
algorithms used for mozilla or IE when it comes to cache cleaning so
I can't say if your images are likely to be killed directly.

Are your images the result of a POST (I guess that they are not).
Are your images the result of a GET with a query string?
GET /image?num=b HTTP/1.1
query string can complicate matter:
"caches MUST NOT treat responses to such URIs as fresh unless
 the server provides an explicit expiration time" (RFC2616).
It does seem like you do provide expiration time so that should not
be a problem.

Do the browsers send nice requests that get a 304 Not Modified as response
or do they send plain GETs?

Also note that you can not force a user to have his cache enabled so that
the browser check/get the image every time is not a violation of the HTTP

Received on Saturday, 23 August 2003 14:06:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC