DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29626>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29626 If-None-Match HTTP/1.1 header not handled correctly Summary: If-None-Match HTTP/1.1 header not handled correctly Product: Slide Version: 2.0 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: WebDAV Server AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a webdav client sends a request like the following GET /slide/files/Letter2004.rtf HTTP/1.1\r\n Accept-Language: en-nz, en-us;q=0.5\r\n If: (<opaquelocktoken:5d6d1a6368cde25d9d5c8bf2530182dd>)\r\n If-None-Match: 87ec191bbb33904a37f1b41d048c2218\r\n Translate: f\r\n User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1\r\n Host: gamma\r\n Connection: Keep-Alive\r\n Cookie: JSESSIONID=4A13D5993D2BDC906C9276A3EF1CE447\r\n (This came from MS Word 2000. NOTE: HTTP/1.1 doesn't define an If header) The server should reply with status 304 if the ETag of the document matches the ETag supplied in the If-None-Match header, otherwise the request should be processed as if no If-None-Match header had been supplied. The code from AbstractWebDavMethod.java will return status 304 if none of the If-None-Match tags match the document, which is the opposite of what should happen commaTokenizer = new StringTokenizer(headerValue, ","); 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. The last test should probably read if (!conditionSatisfied) { I have also discovered that the eTag for a document has " chars wrapped around it (This is done in getETag method), However the client doesn't provide these quotes and an ETag match will never succeed. Is this a bug in the client or the server? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
