- From: Lisa Dusseault <ldusseault@xythos.com>
- Date: Tue, 23 Jul 2002 20:08:52 -0400
- To: <w3c-dist-auth@w3c.org>
The If header has more features than have been used in shipping clients, I believe. To move from Draft Standard to Proposed, we have to pare down the If header definition to those features for which interoperability has been shown. We need to know exactly what features clients are using: - NOT production? - ETags (I think this has already been discussed) - Multiple tagged lists per header? (AND) - Multiple tokens/tags per list? (OR) I propose the following rough text for the If header, assuming that none of the features above are being used by clients in real usage scenarios (not including Litmus or other test suites). It is intended to be a minimalist (KISS) approach to rewriting section 9.4. The text defines the If header in a backward-compatible way: any client following the definition below will send a subset of the syntax that any server implementing RFC2518 will support. Any server implementing the definition below will work with existing clients as far as I know. ----- 9.4 If Header If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = "(" 1*State-token ")" State-token = Coded-URL Coded-URL = "<" absoluteURI ">" The If header was intended to have similar functionality to the If- Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI (state token) which represents state information about a resource. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. All DAV compliant resources MUST honor the If header. The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed. Note that the absoluteURI production is defined in [RFC2396]. 9.4.1 No-tag-list Production The No-tag-list production describes a series of state tokens. 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. If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to. 9.4.1.1 Example - No-tag-list with "or" If: (<opaquelocktoken:a-write-lock-token>) (<opaquelocktoken:another-lock-token>) The previous header would require that any resources within the scope of the method must be locked with one or both of the lock tokens. 9.4.2 Tagged-list Production The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section. The same URI MUST NOT appear more than once in a resource production in an If header. 9.4.2.1 Example - Tagged List If header COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>) <http://www.bar.bar/random>(<locktoken:lock1>) In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, resource1 must be in the state specified by "(<locktoken:a-write-lock-token>)", that is, it must be locked with a lock token of "locktoken:a-write-lock-token". That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header. 9.4.4 Matching Function When performing If header processing, the definition of a matching state token or entity tag is as follows. Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource. 9.4.5 If Header and Non-DAV Compliant Proxies Non-DAV compliant proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- cache" request header MUST be used for the same reason.
Received on Tuesday, 23 July 2002 20:09:30 UTC