Bug 29626 - If-None-Match HTTP/1.1 header not handled correctly
If-None-Match HTTP/1.1 header not handled correctly
Status: RESOLVED FIXED
Product: Slide
Classification: Unclassified
Component: WebDAV Server
2.0
All All
: P3 normal (vote)
: ---
Assigned To: Slide Developer List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-06-17 02:31 UTC by Richard Hardy
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Hardy 2004-06-17 02:31:18 UTC
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?
Comment 1 Stefan L 2004-06-17 13:14:14 UTC
Yes, you are right.

The first (the missing negation) is a real slide bug.
The second is a Bug at the client because RFC2616 whans the etags
in '"', but we shold have a workaraound for that.

I'll try to resolve this next days. 

Thanks, Stefan
Comment 2 Stefan L 2004-06-17 17:35:57 UTC
Fixed on CVS HEAD, Stefan
Comment 3 Richard Hardy 2004-06-17 21:06:15 UTC
If slide expects that the ETag be enclosed in ", should outgoing responses
also add the " char.

ie. Ethereal shows the following packet trace from slide in response to a GET

Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Date: Thu, 17 Jun 2004 20:53:26 GMT\r\n
    Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_jk/1.2.4 mod_ssl/2.8.12
OpenSSL/0.9.6b DAV/1.0.3\r\n
    Set-Cookie: JSESSIONID=5703CE50B15D57ECC96EB56B68EAF785; Path=/slide\r\n
    ETag: f474dea9674df91e55101e77aab915f3\r\n
    Content-Language: en\r\n
    Last-Modified: Thu, 17 Jun 2004 03:23:26 GMT\r\n
    Content-Length: 241\r\n
    Connection: close\r\n
    Content-Type: text/plain\r\n
    \r\n
    Data (241 bytes)

The ETag has no " chars, and the client is just sending back in the
If-None-Match header what it has been sent previously.

Richard.
Comment 4 Stefan L 2004-06-21 08:52:10 UTC
Yes, I've changed this too.