PDA

View Full Version : Fixing HTTP cache management



Talley, Brooks
2004-02-17, 12:49
Hmm -- that surprises me. The only other thing I can think of is adding
a Last-Modified header to try to further clue the browser that this is a
static file and doesn't need to be reloaded:

Last-Modified: Mon, 01 Jan 2001 12:00:00 GMT

Of course, ideally, the Last-Modified would match the file's date/time
on the filesystem -- since it is possible for skins to be updated, a
robust cache management approach would take that into account. However,
for now, I'd settle for clearing my browser's cache if I update a skin
on the server.

I do agree that Cache-Control will probably be (rightfully) ignored by
browsers' HTTP/1.0 implementations, so it won't do any good until
Slimserver goes HTTP/1.1.

Cheers
-b

> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of
> dean blackketter
> Sent: Tuesday, February 17, 2004 11:39 AM
> To: Slim Devices Discussion
> Subject: [slim] Fixing HTTP cache management
>
> One more thing. I added the new header (as you suggested) so
> our headers look like this now:
>
> HTTP/1.0 200 OK
> Expires: Wed, 16 Feb 2005 19:01:46 GMT
> Content-Length: 43
> Connection: close
> Content-Type: image/gif
> Cache-Control: public
>
> And, alas it doesn't seem to help the caching in Safari or Firefox.
> We'll have to wait until Dan fixes us up to HTTP/1.1
>
>
> On Feb 17, 2004, at 10:46 AM, Talley, Brooks wrote:
>
> > Hi, everyone. First, let me say that I'm really impressed with
> > Slimserver and appreciate the volunteer nature of open source
> > development. So, while I've got a suggestion/complaint, I
> absolutely
> > do appreciate the hard work that has gone into Slimserver.
> >
> > However, there's a fairly glaring problem in the way the
> web interface
> > handles browser cache management. You can see the problem
> with each
> > refresh of the web interface -- on both Firefox and IE 6, at least,
> > every .gif image is actually downloaded over and over again
> with each
> > refresh of the page. It's only a couple of K, total, but
> it is a lot
> > of TCP connections, and most browsers will only download a
> few images
> > at once, so the downloads are largely serialized and cause the
> > interface to redraw slowly.
> >
> > The problem stems from a badly formatted Expires: HTTP
> header, and the
> > lack of a cache-control header. Right now, a typical HTTP
> header for
> > a .gif file is:
> >
> > HTTP/1.0 200 OK
> > Connection: close
> > Content-Length: 150
> > Content-Type: image/gif
> > Expires: Wed Feb 16 18:33:55 2005
> >
> > The Expires: header is trying, but it's not correctly
> formatted. In
> > order to really make the image files cacheable, I would recommend
> > changing the format of the Expires: header and adding a
> cache-control
> > header as well.
> >
> > HTTP/1.0 200 OK
> > Connection: close
> > Content-Length: 150
> > Content-Type: image/gif
> > Expires: Wed, Feb 2005 18:33:55 GMT
> > Cache-Control: public
> >
> > ...These simple changes will make the web interface much more
> > responsive, and the periodic reloads will become nearly transparent
> > (limited only by actual HTML generation and transmission speed)
> >
> > I would tackle this myself, but I've never touched perl myself and
> > would probably blow something else up in the attempt.
> Hopefully the
> > change will be trivial for someone else.
> >
> > Cheers
> > -Brooks
> >
> >

dean
2004-02-17, 16:14
That didn't seem to help either...

Looks like we're waiting for HTTP/1.1...


-dean

On Feb 17, 2004, at 11:49 AM, Talley, Brooks wrote:

> Hmm -- that surprises me. The only other thing I can think of is
> adding
> a Last-Modified header to try to further clue the browser that this is
> a
> static file and doesn't need to be reloaded:
>
> Last-Modified: Mon, 01 Jan 2001 12:00:00 GMT
>
> Of course, ideally, the Last-Modified would match the file's date/time
> on the filesystem -- since it is possible for skins to be updated, a
> robust cache management approach would take that into account.
> However,
> for now, I'd settle for clearing my browser's cache if I update a skin
> on the server.
>
> I do agree that Cache-Control will probably be (rightfully) ignored by
> browsers' HTTP/1.0 implementations, so it won't do any good until
> Slimserver goes HTTP/1.1.
>
> Cheers
> -b
>
>> -----Original Message-----
>> From: discuss-bounces (AT) lists (DOT) slimdevices.com
>> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of
>> dean blackketter
>> Sent: Tuesday, February 17, 2004 11:39 AM
>> To: Slim Devices Discussion
>> Subject: [slim] Fixing HTTP cache management
>>
>> One more thing. I added the new header (as you suggested) so
>> our headers look like this now:
>>
>> HTTP/1.0 200 OK
>> Expires: Wed, 16 Feb 2005 19:01:46 GMT
>> Content-Length: 43
>> Connection: close
>> Content-Type: image/gif
>> Cache-Control: public
>>
>> And, alas it doesn't seem to help the caching in Safari or Firefox.
>> We'll have to wait until Dan fixes us up to HTTP/1.1
>>
>>
>> On Feb 17, 2004, at 10:46 AM, Talley, Brooks wrote:
>>
>>> Hi, everyone. First, let me say that I'm really impressed with
>>> Slimserver and appreciate the volunteer nature of open source
>>> development. So, while I've got a suggestion/complaint, I
>> absolutely
>>> do appreciate the hard work that has gone into Slimserver.
>>>
>>> However, there's a fairly glaring problem in the way the
>> web interface
>>> handles browser cache management. You can see the problem
>> with each
>>> refresh of the web interface -- on both Firefox and IE 6, at least,
>>> every .gif image is actually downloaded over and over again
>> with each
>>> refresh of the page. It's only a couple of K, total, but
>> it is a lot
>>> of TCP connections, and most browsers will only download a
>> few images
>>> at once, so the downloads are largely serialized and cause the
>>> interface to redraw slowly.
>>>
>>> The problem stems from a badly formatted Expires: HTTP
>> header, and the
>>> lack of a cache-control header. Right now, a typical HTTP
>> header for
>>> a .gif file is:
>>>
>>> HTTP/1.0 200 OK
>>> Connection: close
>>> Content-Length: 150
>>> Content-Type: image/gif
>>> Expires: Wed Feb 16 18:33:55 2005
>>>
>>> The Expires: header is trying, but it's not correctly
>> formatted. In
>>> order to really make the image files cacheable, I would recommend
>>> changing the format of the Expires: header and adding a
>> cache-control
>>> header as well.
>>>
>>> HTTP/1.0 200 OK
>>> Connection: close
>>> Content-Length: 150
>>> Content-Type: image/gif
>>> Expires: Wed, Feb 2005 18:33:55 GMT
>>> Cache-Control: public
>>>
>>> ...These simple changes will make the web interface much more
>>> responsive, and the periodic reloads will become nearly transparent
>>> (limited only by actual HTML generation and transmission speed)
>>>
>>> I would tackle this myself, but I've never touched perl myself and
>>> would probably blow something else up in the attempt.
>> Hopefully the
>>> change will be trivial for someone else.
>>>
>>> Cheers
>>> -Brooks
>>>
>>>