Re: 505 HTTP Version Not Supported

At 6:36 PM 4/2/96, Roy T. Fielding wrote:
>Please note that, among other things, this allows future applications
>to cease support for older protocols and yet do so in a way that is
>meaningful to older clients.

I think "meaningful" is a relative term. It isn't going to be very useful
for a 0.9 client to receive a 505 message, for example. It isn't going to
be much more useful for a 1.0 client to receive a 505 error if it simply
treats it as an unknown failure. There are other, existing error codes that
are interpreted as meaning a particular requested service or method is
unavailable. If the intent is to let a client know WHY the service or
method is unavailable (i.e., because of a protocol version mismatch), why
don't we just add an entity to the existing error code(s) that clients
already support?

This would allow new clients to provide more info to the user and/or switch
protocol versions to accomodate the server. Existing older clients would
continue to process the error code(s) that existed when they were written
and respond accordingly.

I propose using whichever of the 400, 501, or 503 error codes that makes
sense. It seems that 501 might be the most appropriate, and that adding a
header field like "Failure-Reason:" would allow newer clients to elaborate
on why the request failed without confusing older clients.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                               StarNine Technologies, Inc.
chuck@starnine.com                             http://www.starnine.com/
cshotton@biap.com                                  http://www.biap.com/
                      "What? Me? WebSTAR?"

Received on Wednesday, 3 April 1996 05:22:30 UTC