I'm using slide 2.0. If my interpretation is correct, it looks like there is
a bug with the handling of a request with an If-None-Match header.
>From the header definition:
If any of the entity tags match the entity tag of the entity that would have
been returned in the response to a similar GET request (without the
If-None-Match header) on that resource, or if "*" is given and any current
entity exists for that resource, then the server MUST NOT perform the
requested method, unless required to do so because the resource's
modification date fails to match that supplied in an If-Modified-Since
header field in the request. Instead, if the request method was GET or HEAD,
the server SHOULD respond with a 304 (Not Modified) response, including the
cache- related header fields (particularly ETag) of one of the entities that
matched. For all other request methods, the server MUST respond with a
status of 412 (Precondition Failed).
>From my interpretation, if the tags match, the server should NOT process the
request and consequently if they don't match, the server should process the
request.
However, the logic in AbstractWebdavMethod appears to do the opposite:
boolean conditionSatisfied = true;
while (conditionSatisfied && commaTokenizer.hasMoreTokens()) {
String currentToken = commaTokenizer.nextToken();
if (currentToken.trim().equals(eTag))
conditionSatisfied = false;
}
if (conditionSatisfied) {
// For GET and HEAD, we should respond with
// 304 Not Modified.
// For every other method, 412 Precondition Failed is sent
// back.
...
This is causing problems with web folders returning cached content when it
should not as it uses this header.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
