I had originally started down this path but quickly realized that the checking was going to end up being very provider specific. In all of the implementations I've put together, the checking code always ended up in the Provider implementation. I'm not 100% set on that tho, I'm just not sure it's something that can be moved easily to the framework code.
- James Brian Moseley wrote: > are there any thoughts on supporting the HTTP request headers that > support conditional methods (If-Match, If-Modified-Since, > If-None-Match, If-Unmodified-Since) in the server framework? > > i've added preliminary support in my Provider implementation for > If-Match and If-None-Match, which you can see in the following two > classes: > > <http://viewcvs.osafoundation.org/server/cosmo/trunk/cosmo/src/main/java/org/osaf/cosmo/atom/provider/StandardProvider.java?rev=4186&view=markup> > > have a look at updateEntry() and checkConditionals(). > > <http://viewcvs.osafoundation.org/server/cosmo/trunk/cosmo/src/main/java/org/osaf/cosmo/http/IfMatch.java?rev=4186&view=markup> > > <http://viewcvs.osafoundation.org/server/cosmo/trunk/cosmo/src/main/java/org/osaf/cosmo/http/IfNoneMatch.java?rev=4186&view=markup> > > > i'm thinking it might be better to do these checks in > AbstractRequestHandler's process() or preconditions() methods. we'd > need a way to get the etag for the current state of the target > resource, probably a Target.getEntityTag method. > > i haven't taken a crack at If-Modified-Since/If-Unmodified-Since yet, > but that probably requires a Target.getLastModified method and similar > checks to the If-Match/If-None-Match ones. and there's a little bit of > interaction between these two sets of headers that depend on the > method. but i don't think i'll find any surprises there. > > if this sounds ok, i'll open a jira and work up a patch. thoughts? >
