590507 - Accessing to urls handled by external applications doesn't allow to override the cache

Status: NEW

(Firefox :: File Handling, defect)

Description

[Mike Hommey [:glandium]]

While you can reload web pages, you can't do with, e.g. pdf links. And when the original pdf file changes on the web site, you can't do anything apart from emptying the cache entirely to get the new version if the old version is in your cache. This applies to both saving the file and opening with the external application, and persists after restarting Firefox. This applies to basically all Gecko versions (or, at the very least since 1.8 which is the oldest for which I had the bug reported).

A "simple" testcase was kindly provided in the equivalent Debian bug (I will probably come up with some equivalent xpcshell test):

1) start the following in another terminal:

while true; do
    nc -l -p 1234 -vv <<EOF
HTTP/1.1 200 OK
Date: Sun, 22 Aug 2010 12:02:22 GMT
Server: Apache/2.2.9 (Debian) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8g
Last-Modified: Mon, 05 Jul 2010 10:58:53 GMT
ETag: "c015439-2559f-48aa1d2916b95"
Accept-Ranges: bytes
Content-Length: 30
Vary: User-Agent
Content-Type: application/pdf
Content-Language: en

$(date)
EOF
done

2) rm -fr /tmp/ff-home && mkdir /tmp/ff-home
3) cp ~/.Xauthority /tmp/ff-home
4) HOME=/tmp/ff-home firefox -no-remote http://localhost:1234/testcase1.pdf
5) choose "Save File"
6) click "OK"
7) choose File->Quit
8) HOME=/tmp/ff-home firefox -no-remote http://localhost:1234/testcase1.pdf
9) choose "Save File"
10) click "OK"
11) choose File->Quit
12) head /tmp/ff-home/Desktop/testcase*

Expected results:
4 & 8) netcat prints

connect to [127.0.0.1] from localhost [127.0.0.1] xxxxx

since firefox connects to it to get the file.
12) The timestamps differ

Actual results:
4) netcat prints

connect to [127.0.0.1] from localhost [127.0.0.1] xxxxxxx

8) netcat does not print anything. firefox does not even try to get
the file but uses cached copy instead.
12) the timestamps are the same:

==> /tmp/ff-home/Desktop/testcase1(2).pdf <==
Sun Aug 22 15:11:29 EEST 2010

==> /tmp/ff-home/Desktop/testcase1.pdf <==
Sun Aug 22 15:11:29 EEST 2010

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note that you can change your network settings to revalidate every time if you want to work around this.

Fundamentally, this is a buggy server: it's setting Expires dates that are further into the future than when it plans to change the content, or not setting them at all, in which case the browser has to guess.

The only real options here are to either not cache this stuff at all (why is that desirable?) or to somehow mark it as pre-expired or to expect servers to behave.

Comment 2

[Mike Hommey [:glandium]]

(In reply to comment #1)
> Note that you can change your network settings to revalidate every time if you
> want to work around this.
> 
> Fundamentally, this is a buggy server: it's setting Expires dates that are
> further into the future than when it plans to change the content, or not
> setting them at all, in which case the browser has to guess.

Most servers never set Expires.
 
> The only real options here are to either not cache this stuff at all (why is
> that desirable?) or to somehow mark it as pre-expired or to expect servers to
> behave.

Why not simply ask the server if it has something newer (with If-Modified-Since and/or If-None-Match) ?

Comment 3

[Mike Hommey [:glandium]]

(In reply to comment #2)
> Why not simply ask the server if it has something newer (with If-Modified-Since
> and/or If-None-Match) ?

Wouldn't treating missing Expires as expiring now have that effect, BTW ?