cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Improving ServletConnection to make it cache-aware
Date Tue, 13 Feb 2007 19:01:47 GMT
Daniel Fagerstrom napisaƂ(a):
> I agree with everything this far, it would also be nice to add ETag 
> handling to it. The idea is that the servlet-service-fw should work 
> with all kinds of servlets. And using Last-Modified and ETag headers 
> are the two main ways to handle caching for HTTP, so by supporting 
> both we make caching work for a larger share of the servlets. But the 
> first priority is of course to make it work with the SitemapServlet.
>
> Using ETags together with If-None-Match is analogous to use 
> Last-Modified together with If-Modified-Since as you described above. 
> Some extra care is needed if the servlet called from the 
> ServletConnection returns both an ETag and a Last-Modified header.
Good point. I'll implement this as soon as we are sure that basic 
functionality works well.
>>
>>
>> We should start from making pipelines more HTTP-compliant. This 
>> demands taking If-Modified-Since headers into account and returning 
>> appropriate status code when caching pipeline is processed. Behavior 
>> of non-caching pipelines should not change.
> Agree. There is some getLastModified info on the cachedResponse object 
> in the AbstractCachingProcessingPipeline. It doesn't seem like it is 
> used for setting the Last-Modified header or used together with the 
> If-Modified-Since header however.
It turned out that some functionality was already implemented (there 
were proper support for If-Modified-Since) but some was lacking. I've 
provided patch:
https://issues.apache.org/jira/browse/COCOON-2009
>
> Also it might be that one could use the SourceValidity object (or 
> maybe a hash key based on it) as an ETag.
You mean, Sitemap should create ETag header? It would be hard to 
implement without confusing the pipeline code even more. I'm not anyway 
authoritative but I think pipeline code badly needs redesign.
>> Then we should implement setIfModifiedSince and getIfModifiedSince 
>> from java.net.URLConnection and construct requests according to value 
>> of that property. Also getResponseCode method should be implemented.
>>
>> All changes proposed above will enable us to implement source 
>> validation of ServletSource very easily.
>>
>> Comments? Thoughts?
> Seem like the right direction to me.
Great. I've implemented this functionality and provided patch here: 
https://issues.apache.org/jira/browse/COCOON-2010
Although I've tested it a little bit I would be grateful if you did the 
same. Also some comments on the actual code would be helpful before I 
polish and clean up everything. Please be patient, it's my first attempt 
to mess with some near-core Cocoon stuff.

While implementing this some questions arisen:
1. What about error handling? Should we provide some mechanism for 
passing exception from one servlet to the another? Or maybe just a error 
code and string message is sufficient?
2. Should block request and block response classes be synchronized? I 
mean, do we have take care of synchronization of this classes?
3. See comments in issues for other doubts

I will work now on using these functionality for serving server-side 
resources (xsls, flowscript files etc.) of Ajax and Forms blocks. This 
way we'll get some heavy testing of this new functionality.

-- 
Grzegorz Kossakowski

Mime
View raw message