Hi Vladimir,
That's correct, assuming that Thierry's patch is an original work, then
there is no need for your JCA.
If you plan to submit other patches, that's still something to consider
though.
Best regards,
Jerome
Vladimir Djurovic a écrit :
Thierry,
I agree with your proposal. It's basically what I had in mind.
By the way, if you use your patch, you won't need our signature, right?
Thierry Boileau wrote:
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;
}
}
}
