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). > > - 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. > -- > Jean-Sebastien >
Ok, I have changed the way we are creating the feed id, and also fixed the http headers that were hanging the IE6. I could test the cache portion and I'm getting 304 properly. Could you please take a look and let me know if the IE6 problem is gone ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
