hi all,
I think that you're right, the rule expressed by the rfc 2616 (chapter
14.26) has not been correctly implemented.
From client's point of view, the "if-none-match" condition means: if
I've never met the current entity, the method can be applied.
That is to say :
- if the current entity's tag is not in my own lists of previously met tags
- or if the current entity's tag is one of those I know, but it has
been updated (according to the "if-modified-since" header)
If everybody agrees, I popose to update the code as shown in the
attached file.
best regards,
Thierry Boileau
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
// Is the "if-None-Match" rule followed or not?
if (result == null && getNoneMatch() != null
&& getNoneMatch().size() != 0) {
boolean matched = false;
if (variant != null) {
// If a tag exists
if (variant.getTag() != null) {
// Check if it matches one of the representations
// already cached by the client
Tag tag;
for (Iterator<Tag> iter = getNoneMatch().iterator();
!matched
&& iter.hasNext();) {
tag = iter.next();
matched = tag.equals(variant.getTag(), (Method.GET
.equals(method) || Method.HEAD.equals(method)));
}
// The current representation matches one of those already
// cached by the client
if (matched) {
// check if the current representation has been updated
// since the "if-modified-since" date
Date modifiedSince = getModifiedSince();
matched = ((modifiedSince != null)
&& (variant.getModificationDate() != null) &&
!DateUtils
.after(modifiedSince, variant
.getModificationDate()));
}
}
} else {
matched = getNoneMatch().get(0).equals(Tag.ALL);
}
if (matched) {
if (Method.GET.equals(method) || Method.HEAD.equals(method)) {
result = Status.REDIRECTION_NOT_MODIFIED;
} else {
result = Status.CLIENT_ERROR_PRECONDITION_FAILED;
}
}
}
