- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 8 Oct 2002 17:18:12 -0400
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
- Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED484@SUS-MA1IT01>
Julian makes several good points. One is that we need to address the If header length problem in 2518bis in any case. Even if we did provide a separate header that allowed invalid lock tokens, we still need to use the If header when we want to check for a list of valid lock tokens, or when we want to check for a list of etags. Another good point is that we don't have to argue about whether a client should be allowed to submit invalid lock tokens, because once the If header length problem is addressed (which we have to do anyway), then the "If: <tag> (<token>)(Not <token>)" provides this functionality without defining a header with new semantics. In an earlier message in this thread, the following points were raised as being problems with the "If:...Not..." approach: PROBLEM #1: Servers may not support the OR, and the NOT, correctly, because most clients don't currently use this. This solution HAS NOT been proven, it is only theoretical. It might not work. It will work against all existing servers that are correctly implemented and that don't have an If header length problem, unlike the "new header" approach, which is guaranteed to fail against all existing servers. If the servers are going to be updated, updating them to correctly implement existing semantics seems like a sensible approach to take, especially when the existing semantics are a "logical or" and a "logical not", built-in operators in most programming languages. PROBLEM #2: What if multiple locks are required (e.g. moving a collection that has multiple locked resources? What if the URLs are long? The IF header becomes very long and may be truncated by some proxies. E.g. If: <http://www.ics.uci.edu/users/f/fielding/index.html> (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) <http:// www.ics.uci.edu/users/f/fielding/anotherfile.html> (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>) <http:// www.ics.uci.edu/users/f/fielding/thirdfile.html> (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> NOT <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>) This is the If header length problem. Once we fix the If header problem (which we have to do anyway), there no longer is a need for a new header to get this functionality. PROBLEM #3: Uck, this is really complicated. While it's useful to know that a client can do this with some existing servers, provided they handle it correctly, surely we can do this in a simpler mechanism that is less prone to interoperability problems. A simple header that allows the client to supply lock tokens to use is semantically equivalent to the above example, but shorter, simpler, and easier to implement. Also it can be split across multiple lines. Use-Lock-Tokens: <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> Use-Lock-Tokens: <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> Computer programs are really good at spitting out the same string twice, surrounded by some constant characters. Given the verbosity of XML, and the fact that the Internet is used to stream video, cutting down the number of characters required to identify lock tokens does not strike me as a high priority task. And since any client that wants to interoperate with an existing server has to be able to generate the If form of the request anyway, this is no simplification for an interoperable client that has to be able to generate both forms of the request. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Some thoughts: - it doesn't make sense to raise the header length problem as argument in favor of adding a new header. If the If header length is a problem, it needs to be fixed anyway -- no matter how the other issues are treated - As far as I now understand the client issue (BTW: why aren't the developers of this or these clients not participating in this dicussion??), they want to avoid to re-issue a request that specified a lock token just because the lock went away in the meantime. I *still* don't see why this is a problem -- if the lock was theirs, it's not supposed to go away without reason (such as bad timeout value). If the lock *wasn't* theirs, this is a case of "lock stealing", which certainly doesn't require to be optimized, right? - if a client really really wants the request to succeed either case (lock being present or not), can't he simply submit an If header production such as: If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>)(Not <locktoken:a-write-lock-token>)) ?
Received on Tuesday, 8 October 2002 17:18:56 UTC