Hi, Jerome.

I took a look int Conditions class, and specifically the rule for checking 
If-None-Match header (lines 135-168).
I noticed that, if no matching Etags are found, If-Modified-Since rule is applied. Does this mean that Last-modified header must be used in conjunction with Etag?
Another thing, this code snippet (lines 150-156):

                if (!matched) {
                        Date modifiedSince = getModifiedSince();
                        matched = ((modifiedSince == null)
                                || (variant.getModificationDate() == null) || 
DateUtils
                                .after(modifiedSince, variant
                                        .getModificationDate()));
                    }

I think that here should be !DateUtils.after(modifiedSince,variant.getModificationDat()). In this case, matched will be true if Last-Modified is greater then If-Modified-Since. Then, in the further code, it will cause 304 status.

          if (matched) {
                if (Method.GET.equals(method) || Method.HEAD.equals(method)) {
                    result = Status.REDIRECTION_NOT_MODIFIED;
                } else {
                    result = Status.CLIENT_ERROR_PRECONDITION_FAILED;
                }
            }

I'll try to make a real test for 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

Reply via email to