RE: Interop issue: Proposal for fixing lock token provision

RE: Interop issue: Proposal for fixing lock token provisionI agree with
Geoff.
If there's an interoperability problem, I'd like to see a precise
description, preferrably from the client implementors.
The scenario of a client having a lock token and the etag trying to PUT, and
the server rejecting the request because the lock was lost doesn't really
seem to be a case that needs special treatment. If this is happening
frequently, it's a client (wrong timeout) or server bug that needs to be
fixed. If it doesn't happen frequently, there's no reason to add special
optimzations in RFC2518bis.
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
 -----Original Message-----
 From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
 Sent: Monday, October 07, 2002 9:18 PM
 To: 'Webdav WG'
 Subject: RE: Interop issue: Proposal for fixing lock token provision
 From: Lisa Dusseault [mailto:lisa@xythos.com]
 The proposal to require tagged-lists would not fix everything:
 - The IF header, particularly with URL tagging, is very long and
 can't be split up over several lines.
 I'd be happy to extend the syntax of the If header to allow a ","
 to separate the productions.
 RFC2518 authors: was it just a blunder (:-) that "," is not
 the separator, or was there some good reason why it wasn't used?
 Server writers: what would your server do today if it received
 multiple If headers in a single request?
 - If a lock disappears, the request will fail, even if the client
 wants it to succeed anyway. Round-trip required.
 As indicated in my previous message, I need to see some explanation
 for why clients that don't care about merge prevention are using locks
 in the first place? Why aren't they just using etags?
 - The client doesn't always know which locks are required
 (e.g. DELETE a resource in collection with depth-0
 lock). Round-trip required.
 I don't see any connection between this issue and whether or
 not to use a separate header. If they don't have the right
 list of tokens in the new header, they will still get a failure
 and the same extra round-trip is required.
 Note that if we went with the proposal simply to require tagged
 lists, then the untagged list production should be
 'deprecated', probably by telling clients they MUST NOT use
 untagged list productions. The untagged syntax becomes useless and
 should eventually be removed, though servers must continue to
 support the syntax as long as they want to interoperate with
 pre-existing clients.
 If the untagged syntax becomes useless, I'm happy to deprecate it.
 I'm always happy to delete/deprecate things from the spec if they
 turned out to not be useful ... that simplifies the spec, rather than
 making it more complex.
 I know the proposal to required tagged lists has been considered by
 client developers, and it was considered inferior to the proposal
 for a new header. In practice, it's the situation they currently
 experience - although the specification doesn't say the client
 MUST use tagged-lists, clients eventually come to that realization.
 And still, after programming the client to work that way, they find
 it's complicated and sometimes doesn't work in practice.
 Why is it complicated to create a tagged list? And I'm not sure what
 you mean by "in practice". If you mean "against existing servers",
 then you certainly aren't going to fix things by adding a new header
 that those servers are not expecting.
 My impression from what is being reported is that clients aren't
 aware they should be sending a tagged list, and some servers aren't
 aware that tagged lists need to be implemented. This is simplest
 to fix by making clients aware that they should be sending tagged
 lists, and making servers aware that they should be implementing
 tagged lists.
 Client implementers aren't the largest active constituency on this
 mailing list, and I'm not sure why, because I would guess they are
 the largest constituency of WebDAV implementers. When we do hear a
 solid consistent opinion from the client implementers, I believe it
 should be taken very seriously.
 For there to be demonstrable solid consistent opinions from client
 implementers, we need to see it documented in the mailing list, since
 that is where working group consensus is formed. If client implementers
 feel this is an important issue, it is imperative that they participate
 in this discussion. It's like democracy ... you don't get to complain
 if you don't vote.
 Cheers,
 Geoff
 From: Clemm, Geoff
 Alternatively, we could just say:
 "A client MUST submit a tagged-list If header, using the
 DAV:lock-root of the lock as the tag for that lock token."
 A simple rule for new clients, that will interoperate with
 all correctly implemented old and new servers.
 If any of the tagged-list productions fail, the resource
 that is no longer locked will be indicated with a 412 in
 the multistatus return, telling the client to either remove
 that lock from its table, or request a new lock for that
 resource.
 Cheers,
 Geoff
 -----Original Message-----
 From: Jason Crawford [mailto:nn683849@smallcue.com]
 for compatibility reasons, if the client didn't provide the new submit
 header, the server prudently can be expected to check the If: header
 using whatever semantics that it thinks 2518 specifies regarding
 token submission.
 Similarly, for compatibility reasons (in addition to any correctness
 reasons)
 we might expect the client to continue to submit If headers. For
 compatibility
 reasons a production client wouldn't depend on the server checking
 conditions on
 resources other than ones the server thinks are pertinent, but we can
begin
 to
 test interoperability of that. Eventually though clients would only
 submit
 the If: header for correctness reasons and will feel free to do checks
on
 any resource it feels is appropriate.
 > d) all state productions in a If header are checked, not only those
that
 > apply to "affected" resources by the operation.
 Yes, Initially clients that are spamming the If: header will pay a
price
 for that. But as they eventually move to the new header or stop
 spamming the If: header, that price will no longer be paid.
 The tact that can be taken in production systems is...
 New clients can submit the new header and only the If: clauses that it
 feels
 it wants tested. If the LOCKED error code is returned, they can
resubmit
 to check if the error is just a problem with an old server. This
means
 there
 will be a price for using an old server, but things will still work and
it
 will be
 an incentive to upgrade.
 New clients can submit If: clauses for extra resources, but they will
not
 be
 written to be dependent on submitting extra If: clauses to achieve
 correctness. Not unless they have a way to verify that the server
 supports this. I don't see this as a problem since we aren't
emphasizing
 this feature yet. But eventually it becomes a possibility.
 New servers will know that if a client submits a new header, that it
should
 process that new header. In that case it will also process *all* of
the
 If: header
 clauses and we can test servers to verify that they support this even
if
 production clients don't exercise this feature.
 If new servers receive a request that does not have the new header,
they
 will fall back on whatever code they currently use for If: headers
 submitting
 lock tokens.
 That's what productions systems could do. Testing systems and tightly
 integrated systems could actually fully exercise the new features.