200913 - "when the page is out of date" is assumed after 1 second when no value from the server ?

Status: VERIFIED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Olivier Vit (just a reporter)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

It seems that Mozilla has some built-in 'tuning' which doesn't act in favor of
its speed:
When cache option is set in preferences to "when the page is out of date" and
the web server doesn't define any max-age value nor expiration date, Mozilla
assumes that after something like one second a new request must be sent to the
server

Reproducible: Always

Steps to Reproduce:
1. go to any static web site where expiration is not configured
2. request a page
3. type enter in the URL address bar to request again the same page (do not use
reload button nor control R)
4. look at a trace/proxy tool like
http://www.schmerg.com/WrapUp.asp?file=HttpSniffer.html

Actual Results:  
New requests are being sent after one second

Expected Results:  
Just as a comparison, MS IE 5.01 is waiting much longer (I coudn't find the
delay) before requesting again the elements of the page.
As a result, MS IE looks much faster than Mozilla.
Couldn't Mozilla use a different setting to be more pleasant to the end user,
without sacrificing standard compliance ? (both are acting properly when
expiration and cache control directives are set)
Shouldn't images, css, js and other external content be considered to expire
much later than html ??

Comment 1

[gordon]

Olivier, what is your 'cache validation' preference set to in
Preferences->Advanced->Cache (Everytime, When out of date, Once per session, Never)?

Comment 2

[Olivier Vit (just a reporter)]

Gordon
Thanks for your attention to this

As indicated in the second § (but not in the steps, sorry) my preferences are
set to "when the page is out of date"

Users having a relatively slow connection, or connecting to a server where a few
seconds are needed to deliver a single page, will probably request multiple
times things like spacer images, and this without any benefit nor valuable reason...

Comment 3

[gordon]

Ah, sorry.  I missed reading your cache preference in the original description.

Are you seeing problems with spacer images, or only top level pages?  What
behavior do you see when you try reload instead of using the URL bar?

Comment 4

[Olivier Vit (just a reporter)]

I'm seeing the problem with everything (html, images, flash, video, etc...), on
any page of a site that doesn't explicitly set cache control directives (max-age
and / or expires as described in HTTP 1.1 RFC).

When you use the 'reload' button, Mozilla always sends the http request and adds
a 'pragma=no-cache' directive in it saying it is not looking for 304 not
modified response, but 200 and full content sent back.

Are you looking for test cases ?
I recommend that you get a sniffer tool or proxy with logging to be able to
debug this

Comment 5

[Olivier Vit (just a reporter)]

Hi 

I have built a test case composed of 3 simple files (with one or 2 images/flash)
linked together and put into 2 different folders with 2 different expiration
settings (none and 30 seconds)

You can browse it at
http://verts.montreuil.ouvaton.org/mozilla/no-cache/francais.htm
http://verts.montreuil.ouvaton.org/mozilla/30s/francais.htm

I recommend to browse through the links (should the same as the enter key, isn't
it ?) and loop always in the same order, with an interval between <15s and >15s

I encourage to compare with MS IE (set to Automatically)

I also suggest to look in Mozilla to the information given by ctrl+i : it seems
to give different information from what the http headers say (and it would be
another bug ?)

The command line to read http headers with the perl proxy indicated earlier is
HttpSniffer.pl -r verts.montreuil.ouvaton.org -together -timing
And set Mozilla to use port localhost:8080 as HTTP 1.1 proxy server

Hope this helps
I really believe there is good room for competitive performance improvement here

Comment 6

[Olivier Vit (just a reporter)]

Attachment: archive of the test case being proposed, for local setup

this can be deployed in an apache configuration where mod_expire module is
loaded

Comment 7

[Olivier Vit (just a reporter)]

In fact http://verts.montreuil.ouvaton.org/mozilla/no-cache/francais.htm
is set with 'no cache control set' or 'no-expire' (no-cache is misleading)

Comment 8

[Olivier Vit (just a reporter)]

testing with build 1.5a 2003071004
looks to be solved (no expiration set => no systematic request to the server
within a very short period)

but looks to be using an excessive solution: the internal cache seems to assume
(if Page Info gives data from the internal cache) that the content will expire
in 9 days, 18 hours and some 13seconds.

side effects of this are getting huge (users viewing outdated versions of web sites)

does this require a new bug report ?

Comment 9

[Boris 'pi' Piwinger]

Yes, please file a new bug if you cannot find an existing one. And certainly
this is not a blocker bug.

pi

Comment 10

[Olivier Vit (just a reporter)]

related bugs
http://bugzilla.mozilla.org/show_bug.cgi?id=222429
http://bugzilla.mozilla.org/show_bug.cgi?id=221036

Comment 11

[Olivier Vit (just a reporter)]

on build 2004031508 winxp