Re: Question about header approach to URIQA and 404...

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

Received on Tuesday, 16 March 2004 08:09:05 UTC