PDA

View Full Version : Fixing HTTP cache management



Talley, Brooks
2004-02-17, 11:46
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

Pat Farrell
2004-02-17, 11:56
At 01:46 PM 2/17/2004, Talley, Brooks wrote:
>However, there's a fairly glaring problem in the way the web interface
>handles browser cache management.

This is a known problem, recently added to the bug list.



>The problem stems from a badly formatted Expires: HTTP header, and the
>lack of a cache-control header.

There is more to it, the Slimserver doesn't properly respect or set
the headers, or handle HEAD requests. All related, and fairly
straightforward to correct.

I was thinking of attacking it myself, but my day job keeps interfering.
Maybe later in the week.

Pat

dean
2004-02-17, 11:57
Hi Brooks,

The latest pre-release version has the format of the date string fixed.
You can get it here:

http://www.slimdevices.com/downloads/nightly/latest

But it doesn't have the Cache-Control header set. I'll make that fix.

Dan Sully is working to improve the HTTP server to support HTTP/1.1,
which should also improve performance dramatically.

-dean


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
>
>

Dan Sully
2004-02-17, 11:59
* Talley, Brooks <brooks (AT) frnk (DOT) com> shaped the electrons to say...

>...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.

Thanks Brooks - I've added those changes.

You'll be able to see them in the next nightly build.

-D
--
It does not do to leave a live Dragon out of your calculations..

dean
2004-02-17, 12:39
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
>
>