[Cosmo-dev] Bug 9715

[Travis Vachon]

http://support.microsoft.com/kb/234067

Testing I did indicated that both version of IE do indeed respect the  
cache-control headers. Two birds with one stone!

-Travis

On Oct 17, 2007, at 2:57 PM, Matthew Eernisse wrote:

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