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