- From: Miles Sabin <miles@milessabin.com>
- Date: Wed, 12 Feb 2003 10:52:30 +0000
- To: www-tag@w3.org
I think there's some merit in Patricks proposal, and also in Seariths (and I think another earlier one?) but I think there are a couple of fairly serious problems with the proposal as it stands, * It requires a new request method, or overloading of an existing one. * It doesn't address TimBLs "meta meta" problem. I think, tho', that there's a slight variation on this scheme which fixes both problems. Rather than a new request method we could introduce a new request header (call it Meta:) which can be added as a qualifier to an existing HTTP request. Servers which recognize the qualifier can respond with metadata corresponding to the request, and supply a distinct URI for the metadata itself via the Content-Location response header. This fixes the first problem in that existing client and server toolkits can be used to request and respond with metadata without modification, and metadata requests and responses should pass through proxies unmolested (when used in conjunction with Vary:). Servers which don't recognize the Meta: qualifier will ignore it and perform the requested action (which implies that Meta: should typically only be used in conjunction with GET or HEAD, tho' perhaps support for Meta: could be probed for via an OPTIONS request) and provide the response corresponding to the unqualified request ... even to a Meta: capable client, this behaviour would be fairly reasonable: there's a sense in which an ordinary representation of the requested resource could be treated as information about that resource. It also fixes the second problem in that an independent URI for the metadata is provided via the Content-Location: response header. "Meta meta" requests can be performed by issuing a Meta:-qualified GET on the returned metadata URI, and this chaining could be iterated ad nauseam. One possible extension of this scheme would be to provide the Meta: header with an Accept:-style list of desired metadata content-types. This would allow content negotiation for metadata without clashing with the existing Accept: request header. Another possible variation would be to use a distinct Meta-Location: response header rather than Content-Location:. This would eliminate header overloading on the response side too, and would make it straightforward for a client to distinguish between responses from servers which understand Meta: and those which don't. To a certain extent there's some overlap with the HTTP Extensions Framework, and also with the Expect: mechanism. But both of these have very limited deployment (very few proxies support Expect:) so aren't really suitable as a general solution. Thoughts? Cheers, Miles
Received on Wednesday, 12 February 2003 05:53:07 UTC