- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 11 Apr 2008 07:37:05 +0200
- To: wangxiao@musc.edu
- Cc: Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, "www-tag@w3.org WG" <www-tag@w3.org>
On Apr 11, 2008, at 12:19 AM, Xiaoshu Wang wrote: > I found the 1997's HTTP draft (RFC 2068). http://www.ietf.org/rfc/ > rfc2068.txt, which section 19.6.1.2, describing the LINK. > > The LINK method establishes one or more Link relationships between > the existing resource identified by the Request-URI and other > existing resources. The difference between LINK and other methods > allowing links to be established between resources is that the LINK > method does not allow any message-body to be sent in the request and > does not directly result in the creation of new resources. > > If the request passes through a cache and the Request-URI identifies > a currently cached entity, that entity MUST be removed from the > cache. Responses to this method are not cachable. > > Caches that implement LINK should invalidate cached responses as > defined in section 13.10 for PUT. That is the LINK method. It is not the same as the Link header field. > I don't what kind of "typed" link should be modeled in LINK, but > the requirement for LINK to make sense is that message must be > *empty* because there is no other way to tell the reason of *empty* > message, such as due to copy right restriction etc.. > But the reason for UA2D approach is not based on the assumption of > the message is *empty* but *not empty* because by then they can > avoid 303 with LINK+200. You tell me where is the rational. This has no relation whatsoever to Mark's draft. ....Roy
Received on Friday, 11 April 2008 05:37:44 UTC