On Wed, Jan 5, 2011 at 10:44 PM, Jean-Sebastien Delfino <[email protected]> wrote: > On 01/02/2011 02:37 PM, Luciano Resende wrote: > ... >>>> >>>> I've fixed the refresh issue with TUSCANY-3812 and tested in IE8. I >>>> didn't change anything related to the content-type header containing >>>> type=xxx, so I'm assuming you are still going to have the IE6 issue. >>>> Could you please check and report back if things are working better >>>> for you. >>>> >>>> [1] https://issues.apache.org/jira/browse/TUSCANY-3812 >>>> > > I've tested your fix. IE7,8,9 now correctly refresh the cart. > > Caching still doesn't work though, for two reasons: > > - AtomBindingListenerServlet computes a new feed id each time a feed is > requested (see feed.setId( "Feed" + feed.hashCode());). So multiple requests > for the exact same feed actually return different ids (and associated etags > as they're calculated from the feed content which includes these ids). >
Strange, I thought I had fixed all places to generate the ETag based on the feed MD5 hash (using a common funtion from HTTPUtils). But I guess that, if the feed has a new id per request, then the hash will be different on every request. Let me take a look at this... > - The "Cache-Control: no-cache" header prevents caching as well. > > I think it'd be useful to fix this, as caching is one of the useful > capabilities of a Web infrastructure that REST patterns allow you to > leverage. > > It should be easy: just fix the feed id computation and remove the no-cache > header, then the logic already in AtomBindingListenerServlet should work and > return a 304 Not Modified status when the client presents a matching etag. > > IE6 still hangs as expected. You'll have to remove the "type" parameter to > fix that. > > Hope this helps. Thanks, Hopefully I'll have this fixed sometime tomorrow. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
