RE: 404

> -----Original Message-----
> From: ext Sandro Hawke [mailto:sandro@w3.org]
> Sent: 19 March, 2003 03:25
> To: Stickler Patrick (NMP/Tampere)
> Cc: www-archive@w3.org
> Subject: 404
> 
> 
> 
> Dammit, Patrick, I'm cleaning the kitchen and taking care of three
> kids and it suddenly dawns on me that you're right.

:-)

I'm guessing that this pertains to whether one uses http: URIs to
denote resources which have no web-accessible representations, right?

> Or mostly, at least.  :-)

:-?       (i.e. Eh? ;-)

> I'd like the system to still work without MGET implemented.  

Just for the record, I'm not religiously committed to having the
new methods, I've just failed to find any reasonable way to get
the existing methods to do the job safely and effectively.

Every attempt to use existing methods results in one or more of
(a) multiple system calls, (b) ambiguity, (c) too coarse resolution
of operations, or (d) violation of the web authority domain.

And none of the other proposals I've seen to date, other than MGET,
avoid these problems either.

So, rather than continuing an purely theoretical debate, I've been
completing URIQA, to verify (and demonstrate) the effectiveness of
the MGET approach.

But hey, if someone comes up with an even better solution, and one
that doesn't require new methods, great.

> What if
> GET on the URI for DanC's car returned a 404 (or perhaps something
> similar) with the semantics being "there is no representation for that
> thing (and therefor of course the representation was Not Found)", 

This is how I am thinking. In essence, 404 could be generalized to mean
"the server cannot provide what you asked for" and what was asked for
depends on the request. If GET, then you asked for (and couldn't get) a
representation. If MGET, then you asked for (and couldn't get) a 
description. The complete meaning of 404 is then dependent on the nature
of the request. It simply means the server can't provide what you want,
even though it fully understood what you wanted.

> the error page was in RDF including information like
>    <> isDescribedAt <http://...properSource>
> or maybe just saying all the things the server wants to say about that
> thing, then and there.   

Right.

My prefered behavior, albeit optional, would be for the server to return
a description of a resource for which there is no representation, along
with a 404 error.

> (but if it does that, metadata is messy,
> etc.   it should be some form of redirect, and "resource moved" is not
> the right semantics.)

Well, I don't see much difference between a browser (or server) providing
a nice, pretty formatted HTML page correponding to the 404 status
notification and one that also includes a nice pretty metadata description
of the resource with a clear indication that "no representation is available,
but here's what I know about this thing".

Such a response would be useful both to humans and machine (presuming that
the presentation is based on a stylesheet applied to the RDF, which is
pretty straightforward).

Of course, even if a web server returned a metadata description of a 
resource along with a 404 response, the real purpose and benefit of
having MGET is so that folks (and SW agents) can explicitly ask for
a concise bounded description of a resource rather than a representation.

It's great if a server tells you about a resource as part of a 404
response, but folks have to be able to ask for the resource description
explicitly as well.

> I see no real semantic or operational flaws in that.

Nor do I. 

Cheers,

Patrick

Received on Wednesday, 19 March 2003 02:06:05 UTC