- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 24 Jul 2002 16:21:03 +0200
- To: "Lisa Dusseault" <ldusseault@xythos.com>
- Cc: <w3c-dist-auth@w3c.org>
Speaking for my client code: Am Mittwoch den, 24. Juli 2002, um 02:08, schrieb Lisa Dusseault: > > 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? not used ;) by me. > - ETags (I think this has already been discussed) not used. > - Multiple tagged lists per header? (AND) used and needed. > - Multiple tokens/tags per list? (OR) currently not used. Our server code implements all these features. Removing the "NOT" production is Ok with me, if we need it for proven interoperability. I feel however that the "NOT" production makes the "IF" grammer more complete and see no great burden in its implementation. //Stefan > 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 Wednesday, 24 July 2002 10:21:48 UTC