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
