[Cosmo-dev] Bug 9715

Travis Vachon travis at osafoundation.org
Wed Oct 17 11:45:21 PDT 2007


Ok, I imp'd and tested this last yesterday, but waited until this  
morning for more input to commit. Since I heard a +1 and no negative  
input, I've committed the fix in r5970 and r5971. Review from Brian  
and Matthew would be appreaciated!

-Travis

On Oct 16, 2007, at 5:08 PM, Travis Vachon wrote:

> 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



More information about the cosmo-dev mailing list