[Cosmo-dev] Bug 9715

[Travis Vachon]

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.

More spec:



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  
conditions:

...

       2. It is "fresh enough" (see section 13.2). In the default case,
          this means it meets the least restrictive freshness  
requirement
          of the client, origin server, and cache (see section 14.9); if
          the origin server so specifies, it is the freshness  
requirement
          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:

GET /atom/collection/abcd/full/eim-json

Now I delete event "foo":

DELETE /atom/item/foo-uid

Now I look at the data in another view and then switch back to the  
original view:

GET /atom/collection/abcd/full/eim-json

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  
well.



2) I have a collection with uid efgh containing one event "bar". I  
first fetch the collection:

GET /atom/collection/efgh/full/eim-json

Now I add a new event "foo":

POST /atom/collection/efgh/full/eim-json

<data for "foo">


Finally I refetch the data for efgh:

GET /atom/collection/efgh/full/eim-json

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!

-Travis