Mailing List Archive: WWW Form Bug Report: "Netscape & Mosaic cache files inappropriately when received from Apache/NCSA server" on Linux

WWW Form Bug Report: "Netscape & Mosaic cache files inappropriately when received from Apache/NCSA server" on Linux

Oct 24, 1995, 8:46 AM

Post #1 of 3 (243 views)

No ack sent.

>X-POP3-Rcpt: awm@luers.qosina.com
>From: aixgod@ix.netcom.com
>To: awm@qosina.com
>Date: Tue Oct 24 7:57:06 1995
>Subject: WWW Form Bug Report: "Netscape & Mosaic cache files
inappropriately when received from Apache/NCSA server" on Linux
>
>Submitter: aixgod@ix.netcom.com
>Operating system: Linux, version:
>Extra Modules used:
>URL exhibiting problem:
>
>Symptoms:
>--
>Note that I have not tested this problem on latest version of Apache or
NCSA. Also, note that I think that this is a bug with Netscape 2.0b and
latest version of Mosaic but I thought I better report it to you just in
case. Put a file, such as test123.pdf in a directory on the Apache server.
Now download that file using Netscape 2.0b (for Unix or Windows) by entering
the URL then save the file to disk. Now, copy a new file over test123.pdf
(but name it test123.pdf). Make sure they are different sizes. Now,
download the file using Netscape as above. Save to disk as a different file
name. You will notice that the original test123.pdf and the new test123.pdf
that you saved are the SAME size. This is because Netscape cached the first
test123.pdf and didn't reload from the server the next time you went to
download it. On versions of Netscape prior to 2.0b this behavior doesn't
happen. That made me think that this is a bug with Netscape. However, I
then tried this same s!
> cenario using Netscape 2.0b but using different http servers. Both Apache
(0.6.5) and NCSA exhibited the problem. However, IBM's AIX Server (which is
based on CERN) did NOT exhibit the problem with Netscape 2.0b. Very
strange. So, I then started looking at the HTTP headers output by Cern and
NCSA/Apache and noticed some differences. I modified my Apache source to try
to get the headers as close as possible to the CERN version but it made no
difference. So, this is probably a bug in Netscape 2.0b and Mosaic.
However, it concerns me that it doesn't happen on CERN based servers. That
makes me think that Netscape & Mosaic have tightened up on their HTTP
compliance and that somehow it's not fully compatible with NCSA-based
servers thus resulting in the cache problem. Note that the Last-modified
time was sent by all three servers I tested.
>--
>
>Backtrace:
>--
>
>--
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

Re: WWW Form Bug Report: "Netscape & Mosaic cache files inappropriately when received from Apache/NCSA server" on Linux [ In reply to ]

brian at organic

Oct 24, 1995, 9:25 AM

Post #2 of 3 (240 views)

Permalink

On Tue, 24 Oct 1995, aixgod@ix.netcom.com wrote:
> >Note that I have not tested this problem on latest version of Apache or
> NCSA. Also, note that I think that this is a bug with Netscape 2.0b and
> latest version of Mosaic but I thought I better report it to you just in
> case. Put a file, such as test123.pdf in a directory on the Apache server.
> Now download that file using Netscape 2.0b (for Unix or Windows) by entering
> the URL then save the file to disk. Now, copy a new file over test123.pdf
> (but name it test123.pdf). Make sure they are different sizes.

WAIT - first make sure the second file has a later *modification* time
than the former. If test123.pdf(1) has a later modification date than
test123.pdf(2), when the client does an If-Modified-Since request, the
server will say "Nope, test123.pdf hasn't been changed since you last got
it". This would perfectly describe the situation you were seeing. If
you "touch" the file its modification time will be pushed to the current
time.

The different responses from different servers may be due to either an
incapacity to deal with if-modified-since requests (AIX server?) or a
problem with the date string in the IMS request header (CERN?).

This came up on the workgroup mailing lists a couple of weeks ago, when
Netscape wanted to add a file size parameter to the IMS request line, on
the assumption that one can check file size *or* modification time to
discern between whether a copy in a cache is current.

Brian

> Now,
> download the file using Netscape as above. Save to disk as a different file
> name. You will notice that the original test123.pdf and the new test123.pdf
> that you saved are the SAME size. This is because Netscape cached the first
> test123.pdf and didn't reload from the server the next time you went to
> download it. On versions of Netscape prior to 2.0b this behavior doesn't
> happen. That made me think that this is a bug with Netscape. However, I
> then tried this same s!
> > cenario using Netscape 2.0b but using different http servers. Both Apache
> (0.6.5) and NCSA exhibited the problem. However, IBM's AIX Server (which is
> based on CERN) did NOT exhibit the problem with Netscape 2.0b. Very
> strange. So, I then started looking at the HTTP headers output by Cern and
> NCSA/Apache and noticed some differences. I modified my Apache source to try
> to get the headers as close as possible to the CERN version but it made no
> difference. So, this is probably a bug in Netscape 2.0b and Mosaic.
> However, it concerns me that it doesn't happen on CERN based servers. That
> makes me think that Netscape & Mosaic have tightened up on their HTTP
> compliance and that somehow it's not fully compatible with NCSA-based
> servers thus resulting in the cache problem. Note that the Last-modified
> time was sent by all three servers I tested.

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: WWW Form Bug Report: "Netscape & Mosaic cache files inappropriately when received from Apache/NCSA server" on Linux [ In reply to ]

ben at gonzo

Oct 24, 1995, 12:58 PM

Post #3 of 3 (242 views)

Permalink

>
> On Tue, 24 Oct 1995, aixgod@ix.netcom.com wrote:
> > >Note that I have not tested this problem on latest version of Apache or
> > NCSA. Also, note that I think that this is a bug with Netscape 2.0b and
> > latest version of Mosaic but I thought I better report it to you just in
> > case. Put a file, such as test123.pdf in a directory on the Apache server.
> > Now download that file using Netscape 2.0b (for Unix or Windows) by entering
> > the URL then save the file to disk. Now, copy a new file over test123.pdf
> > (but name it test123.pdf). Make sure they are different sizes.
>
> WAIT - first make sure the second file has a later *modification* time
> than the former. If test123.pdf(1) has a later modification date than
> test123.pdf(2), when the client does an If-Modified-Since request, the
> server will say "Nope, test123.pdf hasn't been changed since you last got
> it". This would perfectly describe the situation you were seeing. If
> you "touch" the file its modification time will be pushed to the current
> time.

Hmmm - you may remember that I was having this problem with Netscape 1.? and
(as it happens) a CERN server. I didn't actually get to the bottom of it, but
it may bear investigation. It does seem that somebody, somewhere isn't handling
it properly, and the common factor seems to be Netscape :-)

>
> The different responses from different servers may be due to either an
> incapacity to deal with if-modified-since requests (AIX server?) or a
> problem with the date string in the IMS request header (CERN?).
>
> This came up on the workgroup mailing lists a couple of weeks ago, when
> Netscape wanted to add a file size parameter to the IMS request line, on
> the assumption that one can check file size *or* modification time to
> discern between whether a copy in a cache is current.

Given the lack of time synchronization on some networks this would mitigate
the confusion. It does seem a shame to resort to such crude measures. Why
didn't they ask for an MD5 checksum, or even just a sum?

For example, on our Web server some files are from an NFS mounted Netware
server (I wouldn't give it processing power, but some fights you don't win).
The Netware server is not time synchronized. I'm not even sure it can be. What
effect this has on IMS I dread to think (especially in more complex cases).

Of course, what we lack here is hard data - everyone is saying I see this
effect or that effect, noone is saying who sent what header line and what
it contained. Probably because Apache is crap at logging this information. Can
I feel a patch coming on?

>
> Brian
>
> > Now,
> > download the file using Netscape as above. Save to disk as a different file
> > name. You will notice that the original test123.pdf and the new test123.pdf
> > that you saved are the SAME size. This is because Netscape cached the first
> > test123.pdf and didn't reload from the server the next time you went to
> > download it. On versions of Netscape prior to 2.0b this behavior doesn't
> > happen. That made me think that this is a bug with Netscape. However, I
> > then tried this same s!
> > > cenario using Netscape 2.0b but using different http servers. Both Apache
> > (0.6.5) and NCSA exhibited the problem. However, IBM's AIX Server (which is
> > based on CERN) did NOT exhibit the problem with Netscape 2.0b. Very
> > strange. So, I then started looking at the HTTP headers output by Cern and
> > NCSA/Apache and noticed some differences. I modified my Apache source to try
> > to get the headers as close as possible to the CERN version but it made no
> > difference. So, this is probably a bug in Netscape 2.0b and Mosaic.
> > However, it concerns me that it doesn't happen on CERN based servers. That
> > makes me think that Netscape & Mosaic have tightened up on their HTTP
> > compliance and that somehow it's not fully compatible with NCSA-based
> > servers thus resulting in the cache problem. Note that the Last-modified
> > time was sent by all three servers I tested.
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
>

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.