RE: If Header: evaluation of all assertions

This is an excellent clarification.

Also, I would clarify what the untagged if production refers to, and it
should probably refer only to the resource named in the Request-URI.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Jason Crawford
> Sent: Saturday, October 12, 2002 10:06 PM
> To: Clemm, Geoff
> Cc: 'Webdav WG'
> Subject: 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 11:14:27 UTC