Hi Adam and Vladimir, Thanks for pushing this issue forward, for the Validation vs Expiration discussion and for the patches.
I'm a bit overwhelmed right now but will have a look at them ASAP in order to fix what needs to be. Meanwhile, do you mind completing the necessary paperwork for the patches (JCA)? http://www.restlet.org/community/contribute Best regards, Jerome > -----Message d'origine----- > De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 13 juillet 2007 20:51 > À : [email protected] > Objet : Re: Entity validation always true. Bug? > > I submitted an issue regarding this: > > http://restlet.tigris.org/issues/show_bug.cgi?id=330 > > Basically, the problem is checking for If-Modified-Since rule > if no matching Etags are found. > I'm not sure if this is required. In the same method, there > is code which checks this logic, so why have it in two > places? Is it for HTTP 1.0/1.1 compatibility, or something else? > I don't have much experience with REST, but from my point > of view, this seems redundant. I would like your comments on > this. > > > Jerome Louvel wrote: > > Hi Vladimir, > > > > The related logic (ETag comparison) is all located inside the > > Conditions.getStatus(Method, Variant) method. > > > > Could you manually test your updated representation on it, > to see if it > > indeed returns 304? > > > > Note that currently the "Cache-Control" header is not > supported. We only > > support the "Last-Modified" and "If-Modified-Since" > headers. See the list of > > unsupported HTTP headers here: > > http://restlet.tigris.org/issues/show_bug.cgi?id=282 > > > > Best regards, > > Jerome > > > >> -----Message d'origine----- > >> De : Vladimir Djurovic [mailto:[EMAIL PROTECTED] > >> Envoyé : jeudi 12 juillet 2007 00:54 > >> À : [email protected] > >> Objet : Re: Entity validation always true. Bug? > >> > >> Peter, > >> > >> can you please tell me what caused this error in your case? > >> I'm having similar problem, and can't find the solution. > >> This is my case: > >> 1. I use GET to generate an entity from an URL, and set > >> maxAge and Etag headers in response. The first time I request > >> this URI, I get 200 status, along with maxAge and Etag > >> headers. This is sample from Liveheaders: > >> > >> HTTP/1.x 200 OK > >> Date: Wed, 11 Jul 2007 22:46:59 GMT > >> Server: Noelios-Restlet-Engine/1.0.1 > >> Content-Type: text/xml > >> Etag: "1184157788023" > >> Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept > >> Cache-Control: max-age=10 > >> Content-Length: 14319 > >> > >> 2. On next request to same URL, I get 304 status, as expected: > >> HTTP/1.x 304 Not Modified > >> Date: Wed, 11 Jul 2007 22:48:21 GMT > >> Server: Noelios-Restlet-Engine/1.0.1 > >> Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept > >> Cache-Control: max-age=10 > >> > >> 3. finally, I update the resource, GET the same URL, and > >> again I get 304, instead of getting new updated entity?? > >> > >> I checked my code, and new Etag value is correctly generated > >> and set in representation. This is code snippet where I do > >> this: > >> > >> > >> if(mediaType.equals(XMLEncoderRepresentation.XML_ENCODED_JAVA_ > >> OBJECT)){ > >> representation = new > >> XMLEncoderRepresentation(notes); > >> } > >> else if(mediaType.equals(MediaType.TEXT_XML)){ > >> representation = new > >> XMLEncoderRepresentation(notes); > >> representation.setMediaType(MediaType.TEXT_XML); > >> } > >> else{ > >> return null; > >> } > >> > >> > >> HeaderControl.setCacheControlHeader(response, maxAge); > >> HeaderControl.setEtagHeader(representation, value); > >> > >> It is my understanding that Restlet should do this > >> autmatically, based on If-none-match and Etag headers. Or > it should > >> be taken care of manually? > >> If anybody has experience with this kind of behavior, > please tell. > >> > >> > >> Peter Lacey wrote: > >>> Sorry to keep responding to my own posts, but it turns > out that the > >>> problem existed between chair and keyboard. Restlet's > >> working dandy. > >>> Pete > >>> > >>> Peter Lacey wrote: > >>>> All, > >>>> > >>>> I have a resource for which I'm generating a strong ETag and a > >>>> Last-Modified header. I first GET the resource without > >> any conditions > >>>> (no If-None-Match and no If-Modified-Since). I next GET > it again > >>>> supplying the ETag and get a 304 response as > appropriate. I then > >>>> update the resource and GET it a third time again > >> supplying the ETag. > >>>> This time, however, I also get a 304 instead of a new > >> representation. > >>>> I have verified that I am indeed generating new ETags and > >> modification > >>>> dates for the updated resource. > >>>> > >>>> Any thoughts? I'm running version 1.0. > >>>> > >>>> Pete > >>>> > >> -- > >> Regards, > >> Vladimr Djurovic > >> mail: [EMAIL PROTECTED] > >> Yahoo Messenger ID: vladadjurovic > > > > -- > Regards, > Vladimr Djurovic > mail: [EMAIL PROTECTED] > Yahoo Messenger ID: vladadjurovic
