Return-Path: 
 <dev-return-6821-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org
Received: (qmail 80576 invoked from network); 19 Apr 2006 13:09:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 19 Apr 2006 13:09:03 -0000
Received: (qmail 30606 invoked by uid 500); 19 Apr 2006 13:08:44 -0000
Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org
Received: (qmail 30573 invoked by uid 500); 19 Apr 2006 13:08:44 -0000
Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:dev@jackrabbit.apache.org>
List-Id: <dev.jackrabbit.apache.org>
Reply-To: dev@jackrabbit.apache.org
Delivered-To: mailing list dev@jackrabbit.apache.org
Received: (qmail 30564 invoked by uid 99); 19 Apr 2006 13:08:44 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Apr 2006 06:08:44 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Apr 2006 06:08:43 -0700
Received: from brutus (localhost.localdomain [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 352DC7142D5
	for <dev@jackrabbit.apache.org>; Wed, 19 Apr 2006 13:07:43 +0000 (GMT)
Message-ID: <15561725.1145452063175.JavaMail.jira@brutus>
Date: Wed, 19 Apr 2006 13:07:43 +0000 (GMT+00:00)
From: "Julian Reschke (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Created: (JCR-406) If header evaluation compliance provlems
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

If header evaluation compliance provlems
----------------------------------------

         Key: JCR-406
         URL: http://issues.apache.org/jira/browse/JCR-406
     Project: Jackrabbit
        Type: Bug

  Components: webdav  
    Reporter: Julian Reschke


There is a problem with the implementation of If header checking in WebdavRequestImpl.matchesIfHeader(), causing warnings and errors in the Litmus test suite, notably test cases cond_put_corrupt_token and fail_cond_put_unlocked.

The main cause seems to be the assumption that evaluation of the If header isn't necessary if the resource isn't locked. That's incorrect, because If header evaluation should occur independently of the state of the resource (even if it doesn't exist). In particular, for a state token known not to represent the current state of the resource, such as "DAV:not-a-lock", the If header

  If: (<DAV:not-a-lock>)
  
should evaluate to false (causing the request to fail with status 412), and consequently,

  If: (<x>) (Not <DAV:not-a-lock>)
  
should always avaluate to true (for any x), because there is one untagged list production evaluating to true; thus the request should proceed.

In RFC2518bis, the WebDAV WG has tried to clarify If header evaluation, see (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-14.html#rfc.section.10.4>).





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira