- From: Yaron Goland <yarong@microsoft.com>
- Date: Sat, 29 Mar 1997 12:16:08 -0800
- To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU>
- Cc: w3c-dist-auth@w3.org
I brought up this problem to Jim Gettys yesterday when we have visiting Microsoft. He agreed that it sucks and feels it is a legitimate issue to be brought up for reconsideration before moving HTTP 1.1 to draft standard. Yaron > -----Original Message----- > From: Roy T. Fielding [SMTP:fielding@kiwi.ICS.UCI.EDU] > Sent: Friday, March 28, 1997 3:15 PM > To: Yaron Goland > Cc: w3c-dist-auth@w3.org > Subject: Re: Change to Lock-Token > > >I was never arguing that lock tokens should be entity tags. What I > was > >arguing for was that the format of a lock token should be the same as > an > >entity tag. This would have, I thought, given us the benefit of being > >able to use lock tokens in if-match headers and thus be able to say > >things like "Don't execute this message unless my lock still exists." > > But that would assume that the lock token is the entity tag, because > the server wouldn't be able to continue the operation if it wasn't. > > >However Roy pointed out that this behavior is illegal. That the HTTP > WG, > >against his vociferous recommendations, decided to make the if-match > >header only available for e-tags. > > Just to clarify, what I said is that the HTTP-WG decided to go with > separate header fields for every conditional, rather than a single > field with a well-defined grammar like > > IF: {eq {Lock "the thing Yaron wanted"}} > > which would allow any number of preconditions and be extensible. > Thus, you will need to define > > If-Lock: "the thing Yaron wanted" > > instead, which, in my considered technichal opinion, sucks. > > .....Roy
Received on Saturday, 29 March 1997 15:16:05 UTC