Re: If header simplification

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