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

AltStyle によって変換されたページ (->オリジナル) /