[Cosmo-dev] Bug 9715

[Andre Mueninghoff]

A user +1 for the most current data always to be presented as edited by
me and/or all other users sharing the same Chandler suite items.
Andre

On Tue, 16 Oct 2007 17:08:34 -0700, "Travis Vachon"
<travis at osafoundation.org> said:
> 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
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev