Re: Proposed issue: site metadata hook (slight variation)

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