W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2004

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

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Tue, 16 Mar 2004 14:35:50 +0100
To: www-rdf-interest@w3.org
Message-ID: <PM-EH.20040316143550.DBE5F.1.1D@>

[this is a re-post of my original message which apparently
didn't get through to the list...]

Hi Patrick,

this is definitely not a representative answer (and very 
apache-centric), but here is how I am currently addressing
representation/metadata serving/discovery:

I'm using apache's url rewriting features with .htaccess
files in order to be able to serve search engine-friendly
html pages (without search args), e.g. I have something like
"ErrorDocument 404 /somepath/catch_404.php".

A not existing "http://myhost.com/pages/about_us.htm" is 
caught by the "catch_404.php" script, which sends a "200 OK"
header and dynamically generated html from, let's say,
AFAIK, that's a widely deployed technique in wcms systems.

So basically, almost any URI would result in a 404 and the 
GETs are handled by one or a limited number of central 
script(s). Adding a "Metadata-Location" header can be done
automatically. Re your use-case "No representation, but a
description", I can see two sub-cases:

1) a description may be served at that URI
2) no description should be directly served at that URI

in the first case, we can serve RDF with an rdf:about="",
and would not need to send a 404. (as already discussed,
people may not like this approach, as the description can
be also considered as a representation which could lead to

the second case could be addressed by sending a 3xx http
header such as a redirect or "see other".

With ".htaccess" you can (afaik) add headers to a 404 
response, but I would personally agree with you that
this wouldn't be a good practice. but with little effort,
a script and the ErrorDocument directive can be used to 
"overwrite" the http status code. If there is neither a 
representation nor a description for a URI (i.e. the
catch script can't handle the request URI), a 404 with
no metadata header would be returned.

as usual, just some thoughts,

Benjamin Nowack

Kruppstr. 82-100
45145 Essen, Germany

On 16.03.2004 08:49:46, 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.
>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?
>Patrick Stickler
>Nokia, Finland
Received on Tuesday, 16 March 2004 08:35:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:50 UTC