[Cosmo-dev] Bug 9715
travis at osafoundation.org
Tue Oct 16 17:08:34 PDT 2007
Good news everyone!
After digging through the HTTP caching spec a bit (http://www.w3.org/
Protocols/rfc2616/rfc2616-sec13.html#sec13) I think that Firefox is
actually behaving correctly in most of the cases where we're seeing
bug 9715. From the spec:
"The goal of caching in HTTP/1.1 is to eliminate the need to send
requests in many cases, and to eliminate the need to send full
responses in many other cases."
The problem we're having is that Firefox is deciding that it does not
need to send a request to get calendar and dashboard data in many cases.
13.1.1 Cache Correctness
A correct cache MUST respond to a request with the most up-to-date
response held by the cache that is appropriate to the request (see
sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
2. It is "fresh enough" (see section 13.2). In the default case,
this means it meets the least restrictive freshness
of the client, origin server, and cache (see section 14.9); if
the origin server so specifies, it is the freshness
of the origin server alone.
13.2 Expiration Model
13.2.1 Server-Specified Expiration
HTTP caching works best when caches can entirely avoid making
requests to the origin server.
13.2.2 Heuristic Expiration
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
worst-case constraints on their results.
So our problem is - you guessed it! - that we're not specifying an
expiration date for our Atom data. As a result, Firefox uses several
other headers to take a guess at when the data is no longer fresh.
Given the nature of our application I'd like to propose that we want
data to expire immediately, forcing the client to revalidate with the
server any time it wants to get data. This doesn't mean we're
throwing away caching completely, it just means the server must
return a 304 to use cached data.
Since this is a little confusing I'll give a couple examples based on
some testing from this morning:
1) I have a collection with uid abcd containing two events "foo" and
"bar". I first fetch the collection:
Now I delete event "foo":
Now I look at the data in another view and then switch back to the
Since we didn't specify an expiration date for the collection data
the browser uses its heuristic to decide that the data in its cache
is fresh and doesn't even bother going back to the server for it.
Since foo was in the original request, foo will be in this request as
2) I have a collection with uid efgh containing one event "bar". I
first fetch the collection:
Now I add a new event "foo":
<data for "foo">
Finally I refetch the data for efgh:
This time according the HTTP spec the collection data should be
invalidated. However, because of the issue mentioned in bug 9715
comment 7 it is not. Fortunately, some testing has indicated that the
caching settings I'm proposing also make this a non-issue, as Firefox
appears to respect the appropriate part of the spec in this regard.
Given the priority of this bug I'm going to start working on a
solution in this vein but I'll be sure to call out my commit to the
appropriate parties for review.
Comments and questions welcome!
More information about the cosmo-dev