If header simplification

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