Re: ISSUE: Returning metainformation on a 201 (Created) response

At 09:23 7/27/98 -0700, Jim Gettys wrote:
>
>a) I'm nervous about adding anything like this at this date.  I'd be happier
>with a separate RFC describing what should happen...  This should have
>been dealt with months ago.

I guess that applies to many of the edits performed now - the reason is
probably that nobody has implemented PUT with etag preconditions until now
- if you want to play with it then you can try out my implementation using
the Web Commander - a libwww sample application [1].

>b) 4) seems a gross hack to me, adding another HEAD class special case
>to the protocol.

I didn't say that it is beautiful but it provides the needed functionality
without breaking existing applications. If people don't care then we can
dream up a new scheme altogether and don't have to be concerned about it here.

>c) I suggest (described in a separate ID) a new header that conveys the
>ETAG.  This solves the race condition.  To get any additional metadata
>that might have changed, you'd perform a HEAD right after the PUT.

This solution doesn't quite work the same way and doesn't have as useful
semantics (special cases etags and allows race conditions on other
metainformation).

>d) you should go see if the WEBDAV folks have worried about this case;
>they are sloppy enough they may have missed it, but then again, they
>may have found it and have another fix for it...

I have forwarded the mail to the webdav mailing list.

Actually the current wording of etags in 14.19 is adequate as (if?) the
requested variant in a first time PUT can be said to be the "requested
variant". Whether that is obvious is another question - and of course it
doesn't work with other metainformation:

The ETag response-header field provides the current value of the entity tag
for the requested variant.

Henrik

[1] http://www.w3.org/WinCom/
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 28 July 1998 11:41:23 UTC