RE: If Header: evaluation of all assertions

Geoff suggested I start a new thread...

I'm going to propose that ALL of the IF: header be evaluated by the server
the server.  I've actually said much of this in a recent
posting on a different topic, and I doubt it got read because
it was buried.  I also probably say it a bit better here this 
time anyway...


RFC2518 seems
to spend a lot of time talking about If: header and all it's
details but not about how it's used to submit lock tokens.  It's use
for lock token submission seems to simply be an afterthought.  It even
says the following when  it begins to talk about the If; header.

   The If header is intended to have similar functionality to the If-
   Match header defined in section 14.24 of [RFC2616].  However the If 
   header is intended for use with any URI which represents state 
   information, referred to as a state token, about a resource as well 
   as ETags.  A typical example of a state token is a lock token, and 
   lock tokens are the only state tokens defined in this specification. 

And I've taken this opening statement, and the fact that it never talks
about lock token submission in the "IF Header" section, to mean that 
the primary purpose of the If: header was for a client to verify various 
aspects of server state (like If-Match) before doing an operation. 

Above I outlined what I thought the *primary* purpose of the If:
header was in 2518.   But there are stray comments in the 2518
that make the If; header's purpose confused.  We've fixed one
of those in 2518bis.  But 2518bis still has the statement that the
server will only check the assertions on the URL's it chooses:

   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. 

With that statement, the semantics and purpose of the If: header 
gets confusing.   It's like the server saying, 
   "you can ask me to check somethings, and I'll only check
    the one's I want, and I won't tell you which one's I
    didn't check"
It (2518) just doesn't make sense.  I undermines what was
presented as the primary purpose of that header:  For the client
to be able to request that the request be contingent on assertions
that he submits.

A trivial, but non fatal, example of the problem the partial
evaluation creates for the client.  Let's say a client has locked
a subtree of the URL space and is working with various resources
in it.   He/She/It GET's and PUT's a lot of resources.  Perhaps it's
making sure all the pages fit some corporate guidelines and tries 
to correct mistakes.  To be careful, it uses the IF: header to make
sure the resources are still locked as it progresses.  But 
unfortunately the server will only evaluate that request if thinks
it needs to.  And for example, it might not evaluate it for GET
requests.  If the resource is a large resource, a lot of time
and bandwidth could be wasted getting the resource if the
operation is later aborted/restarted when the client later finds 
out that the lock has gone away.   If the server had respected
the check in the first place, the client could have corrected
the situation more quickly.

Again, it's not a fatal example, but I think it points out the 
problem this can pose for the client.   Another more significant
example might be a COPY command where one wants to make sure the 
copy of the file one copies is the one that matches an ETAG or
is still locked.   But the server might not even make that 
check before doing the operation.

I'd like to propose that we change the spec to say ALL of the
tagged assertions that the client submits in the IF: header be 
evaluated by the server.

This proposal is not contingent on any of the current IF: header 
related proposals. All proposals should be able to benefit from
this change.

Interoperability... if there are clients out there that submit
assertions on secondary resource that are actually false but 
never evaluated by current servers, then those clients will 
break, but that seems highly unlikely. 

Similarly, because it's unlikely that clients are currently 
submitting assertions on secondary resources that actually
would evaluate to false but passing through, servers can 
feel safe going ahead and evaluating the whole If: header.

The only compatibility issue is transitional.  New clients 
can submit extra assertions, but they don't know if the
server is evaluating all of them because the server might
be following 2518 rather than a new spec.  This means that
for a while, clients can only take advantage of this for
helpful checks, not critical checks.

Thoughts?

J.

------------------------------------------
Phone: 914-784-7569

Received on Sunday, 13 October 2002 01:06:34 UTC