- From: John Tigue <jtigue@DataChannel.com>
- Date: Tue, 7 Jul 1998 14:21:24 -0700
- To: w3c-dist-auth@w3.org
- Cc: Judith Slein <slein@wrc.xerox.com>, John Stracke <francis@netscape.com>
<Judy> <snip /> > The response to a PUT is a more difficult case. A DAV-aware > client would > probably not have tried to do a PUT to a referential resource > in the first > place. For a non-DAV client, the entity of the response > should present the > user with a choice between replacing the target resource and > replacing the > reference. Choosing to replace the target should cause the > client to send > the PUT request to the target resource. Choosing to replace > the reference > should cause the client to send a DELETE request to the > reference, followed > by a resend of the PUT request. What does the response > entity have to be > like to make this happen? > <snip /> </Judy> <John> For the PUT case we could suggest something like the following DTD snippet: <!ELEMENT HTML (HEAD, BODY) > <!ELEMENT HEAD ANY > <!ELEMENT BODY ( A, A, %TheUsualSuspects; ) > And prose explaining that the first A is for the target and the second is for the reference. This way JavaScript can walk into the response and know where the reference pointed to. This type of stuff is simply hints to the server coder as to how to code the response entity. The nice part is that there are no new elements or new attributes on existing HTML elements. </John> <Francis> <snip /> Ideally, the response entity will be irrelevant; the Location: header will suffice. <snip /> </Francis> <John> I agree. I'm just trying to help adoption on the low end by enabling JavaScript. I'm not trying to suggest core protocol stuff be dependent on the response entity. </John>
Received on Tuesday, 7 July 1998 17:24:26 UTC