[Webkit-unassigned] [Bug 17998] When a resource is cached locally, WebKit should follow RFC 2616 "Specific end-to-end revalidation" instead of "Unspecified end-to-end revalidation"

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=17998





------- Comment #11 from mark.hughes at green-ant.com  2008-03-24 10:19 PDT -------
> Please note that my personal opinion is that we should have both reload and
> shift-reload. But in the absence of the latter, it appears obvious that reload
> should fulfill the primary purpose of reloading - which is to guarantee
> freshness of content, regardless of proxy misconfiguration, time zone changes,
> software bugs and other issues that may necessitate full reload. Saving
> bandwidth is a very important consideration, but a secondary one.

So what would the process be to have both options available?

Clearly, it's not a situation where the ideal is one or the other, but in fact
both. I would also think that there could be a client-side preference to force
super-reload when connected to a known bad proxy, or in general (for web dev
testing for instance), or to be OS X Network Locaton specific (so that you
could say to always err on the side of trust on a cellular WiFi network).

I'd like to dig in further to the codebase and see if I could perhaps
contribute this. Does anyone know if the work would be in WebKit, WebCore,
CFNetwork, or is it not community changeable?

> Just as an example, in the past I've personally experienced a situation where I
> couldn't reload stale content that was stuck in a proxy from within Safari - I
> had to open the same page in Firefox and use shift-reload; only after that,
> Safari would display updated content.

As both are just browsers, I believe it would then be advisable to research if
there are any differences between WebKit SuperReload'ing and FF's
SuperReload'ing. If FF can force an upstream to re-cache, and WebKit cannot,
that seems like WebKit needs additional headers/something to force upstreams to
re-cache/re-validate content.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.