Wrong headers slowing www.jboss.org down

[tobias]

Hi!
Pages from www.jboss.org are served with unoptimized response headers. Is there a reason for this or is this just an oversight?

Firebug shows me this for http://www.jboss.org/projects/:

http://www.jboss.org/projects/

Content-Type: text/html;charset=UTF-8
Connection: close
Transfer-Encoding: chunked

Ok, no keep-alice it seems. That's a bit weird, but ok.

http://www.jboss.org/file-access/default/theme/images/common/bkgheader_left.gif

Last-Modified: Fri, 01 Jun 2007 01:41:08 GMT
Expires: Fri, 01 Jun 2007 01:41:08 GMT
Content-Type: image/gif
Connection: close

Again no keep-alive, ok. But Expires set to Last-Modified for a static gif?
Either set Expires to the future or better include a Cache-Control: max-age header.

http://www.jboss.org/file-access/default/theme/images/common/bkgheader_noleft.gif

Last-Modified: Fri, 01 Jun 2007 01:41:08 GMT
Expires: Fri, 01 Jun 2007 01:41:08 GMT
Content-Type: image/gif
Connection: close

Again, no proper caching for static gifs.

For me fetching 10-30 static resources again and again for each page makes the whole thing really slow.

If you look into this, please also check the headers for the MIME-types for PNGs, JPG/jpegs and CSS.

Ciao,
Tobias

[adamw]

Hello,

thanks for spotting this! You're right, we should be setting the expires header for some far-off date for image files - we'll change that on the next site update.

Luckily you don't download the images every time, as we check the if-modified-since header - so you get an empty reply with a 304 (not modified). But the request isn't needed in the first place, anyway.

Adam

[tobias]

It's good to hear that this will be addressed in the next update.

My Wireshark log tells me, that the 304 stuff if not done for me. That would make sense since the Expires header is set to the past (same as the Last-modified).

Even worse is that for every single resource a new TCP connection has to be openend. I'd guess the TCP handshake takes even longer than retransmitting the small resources.

[adamw]

Hello,

well, I get the following:

wget --header='If-Modified-Since: Fri, 01 Jun 2007 01:41:08 GMT' http://www.jboss.org/file-access/default/theme/images/common/jbossorg_logo.gif--2008-04-14 10:12:11-- http://www.jboss.org/file-access/default/theme/images/common/jbossorg_logo.gif
Resolving www.jboss.org... 64.74.196.163
Connecting to www.jboss.org|64.74.196.163|:80... connected.
HTTP request sent, awaiting response... 304 Not Modified

So I think that the 304 is working. Anyway, we'll change the settings for expires soon.

Thanks,
Adam

[tobias]

Adam, you are totally right that the 304 mechanism may be working.

The point is, that the resources are returned with a Expires header that is set to Last-modified. That means the Expires date is always in the past. Thus the browser immediately expires the resource and does not even try to use a If-Modified-Since. Therefor a slight improvement would be leaving the "Expires" headers away. It would be even better if Expires would be set to "request-time + some hours". Alternatively just a Cache-control max-age header.

Cheers!

[adamw]

Hello,

Firefox (2.0, mac os x) does send the If-Modified-Since header, but you are most probably right that not all browser have to do so, confused by the Expires header. As I wrote, we'll fix that during the next site update.

Adam