Patrick Stickler wrote:
>
> I recently recalled a question/suspicion that I had about
> the feasability of obtaining from the response header the URI
> of a resource description in the case where the resource in
> question is denoted by e.g. an http: URI yet has no "normal"
> representation published (only a description).
>
> I.e. I'm talking about cases where a GET/HEAD would return 404
> but an MGET would return a description fo the resource.
>
> If an agent is supposed to get the URI of the description
> via either a GET or HEAD request, then it seems that this
> simply can't work, without changing the fundamental behavior
> of every web server on the globe. I.e., both a GET and HEAD
> will return 404, and hence the agent won't get the header
> it needs to know how to access the description.
>
I think the correct code would be 204 - No Content. From RFC 2616 -
"204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the requested
variant.
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although any
new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields. "
This seems ideally suited for returning URIQA-style data. True, it says
the agent "should not" change its view, but it also says that the agent
"should" update its view in light of new information in the headers.
Cheers,
Tom P