This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: [slightly OT] cache refusal problem with IE, http headers
From: "Ime Smits" <ime@iae.nl>
Date: Tue, 19 Sep 2000 11:41:05 +0200
Hi,
I tried to nail this problem down for over 6 hours now. I use GD.pm to
dynamically generate images used in a dynamically generated Apache::ASP
page. Each image is given a name which is unique (in fact: a md5 on the
original name, width, height, color depth). Some of these images are used in
a javascript onMouseOver. The images are send out to the browser via a
script, with the unique id as $ENV{PATH_INFO}.
Now the odd thing is, both IE's I tried (4.01 and 5.5) seem to /refuse/ to
cache the image oppsed to all Netscape versions, which handle things like
expected. After searching deja, I found out that more people had this
problem, but I only read about javascript preloading and stuff. That's
already been taken care off. If I take a copy of those images and let Apache
handle the request directly from disk, everything is ok.
So I started to get suspicious about headers. I thought maybe IE was choking
on the session-id cookie from Apache::ASP, so I rewrote the Apache::ASP
gateway to plain mod_perl. I messed around with headers, even read
http://perl.apache.org/guide/correct_headers.html three times, but nothing
fixed my problem so far.
I know the problem is not really mod_perl related. I agree on the fact that
this is probably a typical Microsoft inconsistancy. Maybe some of you have
had the same problem.
Below is a sample of the headers it returns. Any ideas? Anything that is
communicated without me seeing it?
Thanks,
Ime
[ime@nobel /tmp]$ wget -S
http://192.168.31.1/mediaexporter.pl/ef6880b34b91e817f8c9973f0e7efe10.png
--10:55:32--
http://192.168.31.1:80/mediaexporter.pl/ef6880b34b91e817f8c9973f0e7efe10.png
=> `ef6880b34b91e817f8c9973f0e7efe10.png.86'
Connecting to 192.168.31.1:80... connected!
HTTP request sent, awaiting response... 200 OK
2 Date: Tue, 19 Sep 2000 09:21:34 GMT
3 Server: Apache/1.3.12 (Unix) mod_perl/1.21_03
4 Expires: Thu, 19 Oct 2000 08:52:50 GMT
5 Last-Modified: Tue, 19 Sep 2000 09:20:46 GMT
6 Cache-Control: public
7 ETag: ef6880b34b91e817f8c9973f0e7efe10
8 Content-Length: 294
9 Connection: close
10 Content-Type: image/png
and here for the same image, but as a normal static file fron disk:
HTTP request sent, awaiting response... 200 OK
2 Date: Tue, 19 Sep 2000 09:22:50 GMT
3 Last-Modified: Tue, 19 Sep 2000 09:22:10 GMT
4 Server: Apache/1.3.9 (Unix) mod_perl/1.21_03
5 ETag: "477b1-147-39b3889d"
6 Accept-Ranges: bytes
7 Connection: close
8 Content-Length: 327
9 Content-Type: image/png
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: Joshua Chamas <joshua@chamas.com>
Date: Tue, 19 Sep 2000 02:55:26 -0700
In your Apache::ASP version, try setting Expires to tell IE
to cache explicitly...
$Response->{Expires} = 86400; # cache until tomorrow
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "Ime Smits" <ime@iae.nl>
Date: Tue, 19 Sep 2000 12:02:27 +0200
In your Apache::ASP version, try setting Expires to tell IE
| to cache explicitly...
| $Response->{Expires} = 86400; # cache until tomorrow
I did that. And and also tried
$r->add_header('Expires',HTTP::Date::time2str(time+86400)); in a normal .pl
file. In fact, the first header dump in my previous message shows the header
doing it that way.
Other things I tried:
* "Cache-Control: public" (defaults to 'private' in Apache::ASP)
* Killing the Cache-Control header all together
* "Last-Modified:", tried in 5 minutes, in a month, in a year (the maximum
according to HTTP/1.1 standards), somewhere in 2038.
* "Expires:", idem dito
* Minimal header (just content-type and length)
* Telling IE (both 4.01 and 5.5) to *Never check*
IMHO, that last one is the weirdest of all.
Ime
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: Joshua Chamas <joshua@chamas.com>
Date: Tue, 19 Sep 2000 03:25:54 -0700
I saw your header, but couldn't tell that it was for tomorrow,
with the GMT time zone info. I don't read GMT go figure ;)
What I would recommend is trying to match the headers exactly
as when serving up the static file since we know that works,
oh and make sure the file extension is the same too. I saw your
URL for the modperl request as:
http://192.168.31.1/mediaexporter.pl/ef6880b34b91e817f8c9973f0e7efe10.png
... maybe IE is "smart" enough to see the .pl in the path and guess
that this is a dynamic request. If your URL looks more like:
http://192.168.31.1/mediaexporter/ef6880b34b91e817f8c9973f0e7efe10.png
that might help.(?) Best of luck. These browsers can be tough.
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "Ime Smits" <ime@iae.nl>
Date: Tue, 19 Sep 2000 12:36:43 +0200
I saw your header, but couldn't tell that it was for tomorrow,
| with the GMT time zone info. I don't read GMT go figure ;)
Euhmmm... If I'm not mistaken, 19 october actually is next *month*, even in
your timezone ;)
| ... maybe IE is "smart" enough to see the .pl in the path and guess
| that this is a dynamic request. If your URL looks more like:
| http://192.168.31.1/mediaexporter/ef6880b34b91e817f8c9973f0e7efe10.png
| that might help.(?) Best of luck. These browsers can be tough.
Tried "RewriteRule ^/mediaexporter/(.+) /mediaexporter.pl/$1", same
problem. Does anybody know of a tool to get a complete log on every piece of
information communicated between browser and server?
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "G.W. Haywood" <ged@www.jubileegroup.co.uk>
Date: Tue, 19 Sep 2000 11:40:42 +0100 (BST)
Hi there,
On Tue, 19 Sep 2000, Ime Smits wrote:
> Does anybody know of a tool to get a complete log on every piece of
> information communicated between browser and server?
'sfunny, I asked Josh the same question a couple of weeks ago...
I think it's called a packet sniffer. I've had some success with the
debug flag in the pppd "options" file but you've got to *really* want
to know =:o
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: Chris Winters <cwinters@intes.net>
Date: Tue, 19 Sep 2000 08:13:45 -0400
G.W. Haywood (ged@www.jubileegroup.co.uk) [000919 06:54]:
> Hi there,
>
> On Tue, 19 Sep 2000, Ime Smits wrote:
>
> > Does anybody know of a tool to get a complete log on every piece of
> > information communicated between browser and server?
>
> 'sfunny, I asked Josh the same question a couple of weeks ago...
>
> I think it's called a packet sniffer. I've had some success with the
> debug flag in the pppd "options" file but you've got to *really* want
> to know =:o
>
> 73,
> Ged.
There's a nifty little GTK program that displays all headers to and
from a client (and content too, if I remember right) -- just set it
listening on a particular port and then tell your browser to connect
to that port as a proxy. Super useful.
it's called 'wsnitch' and it's at:
http://www.geocities.com/denis_leconte/gnomewsnitch.html
BTW: I found this after someone mentioned on the modperl list about
three or four months ago :)
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "Ime Smits" <ime@iae.nl>
Date: Tue, 19 Sep 2000 14:18:27 +0200
OK, did it the hardway: after a lot of tcpdump -i -s 500, grepping and
stringing, I tackled it. Halfway.
IMHO, it boils down to both a IE bug and a somehow 'hidden' feature of
Apache. It seems that on script execution an extra header "Vary: Host" is
sent to the browser.
This is what the RFC's say:
"A Vary field value consisting of a list of field-names signals that the
representation selected for the response is based on a selection algorithm
which considers ONLY the listed request-header field values in selecting the
most appropriate representation."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
So a "Vary: Host" would tell the browser that it can assume the content to
bee static as long as the 'Host' header in a HTTP request doesn't change.
Appearantly, this header is misinterpreted by IE, causing it to get
everything fresh from the server causing the onmouseover delays. I suspect
Microsoft of being just too lazy to even evaluate the right hand side of the
Vary header.
Apache docs mention about "CacheNegotiatedDocs", but that doesn't seem to
get rid of the Vary header. I did a quick and dirty fix for the moment by
compiling Apache with --enable-module=headers and a "Headers unset Vary" in
httpd.conf, but there should be a better way. Suggestions are welcome.
Ime
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "Alexander Farber (EED)" <eedalf@eed.ericsson.se>
Date: Tue, 19 Sep 2000 14:44:43 +0200
Ime Smits wrote:
> Below is a sample of the headers it returns. Any ideas? Anything that is
> communicated without me seeing it?
>
> 8 Content-Length: 294
>
> and here for the same image, but as a normal static file fron disk:
> 8 Content-Length: 327
How come that the sizes are different?
===
Subject: Re: [slightly OT] cache refusal problem with IE, http headers
From: "Ime Smits" <ime@iae.nl>
Date: Tue, 19 Sep 2000 16:42:04 +0200
8 Content-Length: 294
| > 8 Content-Length: 327
| How come that the sizes are different?
The images are dynamically generated png's with GD, but however the contents
may change every time you view a page, it's not necessary for the browser to
constantly get a fresh copy when doing a javascript onmouseover.
===