RE: Change to Lock-Token

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