Bug 5499 – Page reload does not send any cache control headers

• Component: Page Loading
• Status: RESOLVED FIXED

[Nicolas Sandri]

There is no difference between loading a page and reloading a page except for the local cache. Because 
headers are strictly same, cache or proxy server between client browser and http server are not 
refreshed.
The HTTP 1.1 protocol RFC describe the request directives (in 14.9.4, Cache Revalidation and Reload 
Controls) needed to refresh page content.
Since there's a growing use of NetCache by ISPs to save their bandwidth, this problem (I already 
reported two years ago using the Safari 1.0 bug report) can really be a missing function for users 
(especially if they're web developer like me).
Firefox, for example, refresh correctly the page, adding the needed directives to its requests :
   If-Modified-Since: Wed, 12 Oct 2005 17:09:46 GMT
   If-None-Match: "1a54-434d435a"
   Cache-Control: max-age=0
Since I update my website's pages, I need to use Firefox to ask the cache server to refresh its contents 
and then use Safari to see it.

When this will be corrected, the button could be renamed "Refresh" instead of "Reload" ;)

[Nicolas Sandri]

Created attachment 4474 [details]
Safari load headers dump

[Nicolas Sandri]

Created attachment 4475 [details]
Safari reload headers dump

[Nicolas Sandri]

Created attachment 4476 [details]
Firefox load headers dump

[Nicolas Sandri]

Created attachment 4477 [details]
Firefox reload headers dump

[Joost de Valk (AlthA)]

Reassigning to webkit-unassigned, to make sure more people see this.

[Alexey Proskuryakov]

This is related to bug 7414 (shift-reload functionality).

[Alexey Proskuryakov]

Created attachment 8891 [details]
proposed fix

This fixes both manual reload and window.location.reload; not sure if there are other ways to cause reload that should send cache control headers (window.location.assign to the same URL doesn't do that in Firefox).

Unfortunately, there doesn't seem to be a way to send If-Modified-Since together with max-age=0 (in other words, to validate freshness) with NSURLRequest, rdar://4590785. This doesn't affect correctness, but wastes bandwidth.

The TransferJob-related code in WebCore::Frame seemed to be unused, other than for passing response HTTP headers.

[Darin Adler]

Comment on attachment 8891 [details]
proposed fix

r=me

I'm not sure about that FIXME in loadRequest: -- seems a little cryptic to me. It's fine to add a FIXME, but I'd like it to be more specific if possible.

Can the include of TransferJob.h be removed from Frame.cpp?

[Alexey Proskuryakov]

Committed revision 14920.

(In reply to comment #8)
> I'm not sure about that FIXME in loadRequest: -- seems a little cryptic to me.
> It's fine to add a FIXME, but I'd like it to be more specific if possible.

Changed the wording and also the meaning. There's probably nothing else needed to reset, but doing this in loadRequest: looks a bit hackish to me.

> Can the include of TransferJob.h be removed from Frame.cpp?

My patch was already removing it - am I missing something?