[Cosmo-dev] Bug 9715

[Matthew Eernisse]

The only question I'd have regarding r5971 is whether it will now cause 
problems in IE -- which is what the query-string hack was originally 
there for, IIRC.

I'm fuzzy on details, but I do see the specific IE-test there in the 
conditional:

if (dojo.render.html.ie || 
cosmo.ui.conf.getBooleanValue("preventDataCaching")) { ...

Bug 9715 and its fix are Firefox-specific, right?


Matthew


Travis Vachon wrote:
> 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
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>