Question about header approach to URIQA and 404...

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.

True, even a 404 status response includes a header, and
the description URI *could* be there, but I have the
(possibly incorrect) impression that header augmentation via
mechanisms such as .htaccess are not going to work if there
is no representation at all.

Yes, let me say before anyone else jumps in to say it, one
could easily modify the server behavior for GET and HEAD
requests to always include that header no matter what the
status code of the response is -- but that seems to me to
be just as much a change to the server (or even more) as
adding native support for MGET/MPUT/MDELETE.

For those much better informed and familiar with various
server implementations, does this issue reflect your
experiences -- can the same mechanisms which will insert
a header into a successful GET or HEAD response (e.g. '.htaccess',
etc.) still work if there is no "traditional" representation
available, i.e. if the GET/HEAD returns 404?

Cheers,

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Tuesday, 16 March 2004 01:50:23 UTC