Absolutely! I know my client doesn't because it passes the response code
between routines as a number and saves it for later referral.
For my application, the actual text response is useless.
> While, I don't wish to create a separate server response for every
> eventuality (Henrik's point is well taken) I do believe that we need some
> way of conveying machine readable semantics in the server response as a
> fundamental piece of quality of service.
>
> Since the headers are currently a flat information space, the obvious thing
> to do is create a new header response for something like a busy remote
> server. Perhaps the guideline for adding a new response should be whether
> making the response machine readable makes any sense versus just displaying
> a response to the user which requires them to take some action. This
> implies that clients always display a 5xx response to the user if an
> automatic action is not possible. This fits with our current model for
> response codes in the 2xx, 3xx, and 4xx classes as well.
That brings up a question I was grappling with yesterday...
I am building the start of a generic WWW library for Perl (i.e. given
any URL and method name, it will perform that method using that URL's
scheme and return the response as if it was an HTTP response). The library
will start with support for HTTP and FILE and more schemes will
be added (collaboratively, I hope) over time.
The question is: what error code should be passed back if a particular
scheme has not yet been implemented? This is similar to the
"501 Not Implemented" response from a server, but it needs to be clear
that the error is due to a limitation of the client.
Currently, I am using "601 Not Implemented". Would 101 be better?
Should there be a block of numbers set aside for internal client responses?
How do other clients handle this?
....Roy Fielding ICS Grad Student, University of California, Irvine USA
(fielding@ics.uci.edu)
<A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>