75098 - Pages without explicit "Last-Modified" HTTP header shouldn't be cached.

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Si Ly]

Pages without explicit "Last-Modified" and other cache-validation HTTP headers
should not be fetched from the cache if user clicks on a link.  Without those
headers, there's no way to validate a cache entry.  (Note that clicking on a
link is not the same as browsing session history with "back" or "forward", which
should use the cache.  See RFC 2616, Section 13.13)

This is similar to Bug #73490, but I would say it should behave the same with or
without a '?' in the URL.  Basically, no expiration info in the HTTP headers
should tell Mozilla not to use the cache, except for session history).

This is how Netscape 4/6, IE, and old-cache Mozilla works.  I can't tell from
RFC 2616 whether this is actually required, but most websites just assume that's
how clients work.  For example, most shopping carts would not refresh properly
with Mozilla 0.9.  To reproduce, go to http://www.amazon.com/ and do the
following:

1. Add a product to your cart.
2. Click "view cart" (top of page).  This URL will be cached.
3. Add a different product to your cart.  Note that cart is updated because URL
is different from #2.
4. Click "view cart" again.  Note that content of cart did not include the item
added from #3 because the page is fetched from the cache.

I also have a very simple test page at http://www.sily.net/cache-test.jsp

Comment 1

[Darin Fisher]

agreed.

Comment 2

[Darin Fisher]

even if a webserver does not provide explicit cache control headers, we can
still use the Date header to send If-modified-since requests, instead of
refetching entire documents.

Comment 3

[Si Ly]

I think If-modified-since is a nice-to-have, but it probably won't help save a
re-fetch in this case. If the server doesn't send a Last-Modified, then it
probably doesn't know how to handle If-modified-since either.  This is because
the page is probably dynamically generated.  The web application developer
probably didn't care or know how to deal with these headers.  And in a
multi-tiered environment, he can't do anything about it because the application
server might not be on the same machine as the web server.  And he doesn't have
an easy way to ensure that there's no clock skew between those two machines. 
(The Date header usually comes from the web server, but the If-modified-since
header would have to be examined by the application server.)

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

See bug 46825 (a bug on the old cache) for a discussion of the correct behavior.

Comment 5

[Darin Fisher]

I've checked in a patch for bug 75679 that includes the fix for this problem
as well.  Only if the user has set their cache validation settings to NEVER
will we NOT validate/reload pages without an explicit "Last-Modified" header.
In all other cases, these pages will be kept up-to-date each time the page
is visited via normal browsing (if browsing via history, then the cached
page will be shown instead).

Comment 6

[Si Ly]

Perfect.

Comment 7

[benc]

TEST:
This is not the most ideal test, but here is what I did.

If found a page that doesn't have a Last-Modified header:
http://www.packetgram.com/pktg/

I loaded it twice via the URL field, to see if it would pull from the server. I
also checked to verify it did an If-Modified-Since on the second request. I
checked every cache mode.

It pulls everytime, except for "Never", which seems like what it should do.

VERIFIED:
Mozilla 0.9 allplats.