- From: Miles Sabin <miles@milessabin.com>
- Date: Wed, 12 Feb 2003 15:22:32 +0000
- To: www-tag@w3.org
Jeffrey Winter wrote, > > But there's a crucial difference. My proposal (which is really only > > a minor variation on Patricks) uses a _request_ header, to allow > > clients to actively request metadata. The current distributed- > > registry proposal only allows servers to provide unsolicited > metadata responses. > > The problem is that if you are using a GET with a Meta: header, > then are you really getting a representation of the resource? It > seems to be stretching the semantics of the GET method. Yes, a little. But only by the mutual consent of the client and the server. I guess this isn't a million miles away from the semantics of the HTTP Upgrade: header. > Also, how do you PUT/DELETE/POST to that metadata, just using the > Metadata: header? It seems morally equivalent to a set of M(XXXX) > methods which has the same problem. It _is_ the moral of Patricks M(XXX) methods ... but _without_ the problems ;-) > The only issue with having the OPTIONS method return > a Meta-Location: header is that it takes multiple requests > to obtain the data, an OPTIONS request to get the uri of the > metadata, and a GET on that uri to actually obtain it. I see > this as both beneficial and necessary. I don't think that is the only issue. Support for OPTIONS is far less widespread than support for extension request/response headers. Cheers, Miles
Received on Wednesday, 12 February 2003 10:23:03 UTC