Subject: Issue 147 - Depth vs Conditional headers

From: Julian Reschke <[email-masked]>
Date: Sat, 07 Jan 2006 13:26:11 +0100

See <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147>.

Hi,

it seems that RFC2518 and RFC2518bis share a major problem in defining 
how the Depth header and other headers interact. In Section 9.2, RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.2.p.9>) says:

"Any headers on a method that has a defined interaction with the Depth 
header MUST be applied to all resources in the scope of the method 
except where alternative behavior is explicitly defined. For example, an 
If-Match header will have its value applied against every resource in 
the method's scope and will cause the method to fail if the header fails 
to match."

Let's look at an example. A COPY request with Depth infinity having an 
If-Match header such as:

   COPY /foo HTTP/1.1
   Host: example.com
   Destination: http://example.com/bar
   If-Match: "123"
   Depth: Infinity

would need to evaluate the If-Match header for each resource to be 
copied. There are two major problems with this:

1) It would be extremely expensive. For a copy of a large tree, the 
server would need check entity tags on any member before even starting 
the copy operation, because it would need to fail with a top-level 412 
status otherwise.

2) It's not being implemented in today's servers, see 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=147#c3>.

Now for the "If" header itself (this is the only applicable header 
defined in RFC2518 itself), RFC2518bis already states that it only 
applies to the Request-URI (when the untagged form is used).

The only simple fix I can currently think of for the Depth header 
definition though is to revert the definition at least for those headers 
where we know that servers aren't doing it as defined (and also are not 
likely to change their behavior). Such as replace the quoted paragraph by:

"Any headers on a method that has a defined interaction with the Depth 
header MUST be applied to all resources in the scope of the method 
except where alternative behavior is explicitly defined, and except for 
the If-Dash headers defined in RFC2616 and the If header defined in 
Section x.xy)."

Feedback appreciated (I mean it! :-),

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 7 Jan 2006 14:44:28 -0500

I don't see an alternative.  The only thing I'd suggest is to
slightly simplify the qualifier by not referring to the If header
(since we can state in the definition of If header that it
doesn't recurse via Depth), i.e.:

"Any headers on a method that has a defined interaction with the Depth 
header MUST be applied to all resources in the scope of the method 
except where alternative behavior is explicitly defined, and except for 
the If-* headers defined in RFC2616."

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 07 Jan 2006 20:58:48 +0100

> the If-* headers defined in RFC2616."

The reason I mentioned "If" as well is because people may still assume 
that a If header in tagged list form is going to be applied to all 
resources in scope, thus I preferred to be safe. If I'm the only one 
seeing that as a potential for confusion we can of course remove that 
statement.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 7 Jan 2006 16:04:40 -0500

To be clear, I wasn't suggesting that we not say anything about
"If", but rather that we don't say anything about "If" in that
sentence, and instead talk about it's interaction with Depth in
the section in which the "If" header is defined.  That way, the
fact that "If" is an exception is covered by the clause that says
"except where alternative behavior is explicity defined".

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sun, 08 Jan 2006 15:17:32 +0100

> "except where alternative behavior is explicity defined".

I see.

New proposed change:

Section 9., para. 17:
OLD:

     Any headers on a method that has a defined interaction with the Depth
     header MUST be applied to all resources in the scope of the method
     except where alternative behavior is explicitly defined.  For
     example, an If-Match header will have its value applied against every
     resource in the method's scope and will cause the method to fail if
     the header fails to match.

NEW:

     Any headers on a method that has a defined interaction with the Depth
     header MUST be applied to all resources in the scope of the method
     except where alternative behavior is explicitly defined, and except
     for the If-Dash headers defined in [RFC2616].

Section 9., para. 31:
OLD:

     The No-tag-list production describes a series of state tokens and
     ETags.  If multiple No-tag-list productions are used then one only
     needs to match the state of the resource for the method to be allowed
     to continue.  All untagged tokens apply to the resource identified in
     the Request-URI.

NEW:

     The No-tag-list production describes a series of state tokens and
     ETags.  If multiple No-tag-list productions are used then one only
     needs to match the state of the resource for the method to be allowed
     to continue.  All untagged tokens apply to the resource identified in
     the Request-URI (this includes the case where the If header is
     applied to resources in scope of a Depth: Infinity request).

Appendix E., para. 12:
OLD:

     Support for UTF-16 now required (ref (Section 18)).

NEW:

     The If header and the If-Dash headers (defined in [RFC2616]) have
     been explicitly excluded from the Depth: Infinify rules (see
     Section 9.2).

     Support for UTF-16 now required (ref (Section 18)).