RE: 404

> -----Original Message-----
> From: ext Sandro Hawke []
> Sent: 19 March, 2003 03:43
> Cc: Stickler Patrick (NMP/Tampere);
> Subject: Re: 404 
> > I'd like the system to still work without MGET implemented.  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)", and
> eh, I guess "303 See Other" is the best fit, with "302 Found" being
> next best.  

Well, as I mentioned in my last response, I see no problem using 404
and including along with it an optional description. I.e. just because
a representation cannot be found, per a GET request, does not mean that
a description cannot be found, per an MGET request.

SW savvy applications will (or should) understand that.

If existing status codes are to be used in conjunction with SW behavior,
then we'll have to be very careful about both explicit and implicit
representation-specific semantics bound up in their interpretation.

With URIQA, I'm presently using a mixture of existing codes where they
seem OK with some new ones where the existing codes just didn't fit.

600  True              (response to MAFFIRM method)
601  Indeterminable    (response to MAFFIRM method)
602  Added             (response to MPUT, MUPDATE, analogous to 201, Created)

I considered using 201 rather than 602, but since one is
adding statements to an existing description rather than creating a
description outright, it seemed an ill fit. But perhaps 201 could
be used, with sufficient clarification that what is created are
statements in the description rather than the entire description.
I'll have to think on that one some more.

600 and 601 clearly have no counterpart in HTTP 1.1, though.



Received on Wednesday, 19 March 2003 02:20:47 UTC