W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: 505 HTTP Version Not Supported

From: Chuck Shotton <cshotton@biap.com>
Date: Wed, 3 Apr 1996 10:32:10 -0600
Message-Id: <v02140b08ad88570afb34@[198.64.247.72]>
To: Daniel DuBois <ddubois@spyglass.com>, "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 10:04 AM 4/3/96, Daniel DuBois wrote:
>At 07:17 AM 4/3/96 -0600, Chuck Shotton wrote:

>>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.
>
>If they don't understand 1.1, how would they be able to switch protocol
>versions?  There's no 1.05 they could be theoretically upgrading to from 1.0.

No kidding. You're missing the whole point of my message. Existing clients
already know how to do something reasonably smart with existing error
numbers. Existing clients haven't a clue about 505. Adding a header field
to an existing error code would allow existing clients to retain their
current behavior (a good thing) while enabling new clients to determine
failure reasons and perhaps renegotiate a different HTTP version (another
good thing).

Adding a new, unknown error code that isn't supported by existing clients
would elicit an undetermined response from a large variety of the client
base (a bad thing) and would mean that only new clients would be forward
compatible with the 505 error code (an OK thing.) As usual, the solution
seems to be to make the HTTP protocol bigger instead of smarter. All I
advocated was using an existing error code that means "the server cannot
honor that request" and expounding on it in some header fields. This seems
a much less fragile alternative to assuming all clients will understand and
do something smart with a 505 error code that they've never heard of
before.

>>Existing older clients would
>>continue to process the error code(s) that existed when they were written
>>and respond accordingly.
>
>The appropriate response to a 505 for a 1.0 client is the same as for a 500:
>total failure, report the entity body to the user.  Following the logic of
>your line of arguement, we should just get rid of all 5xx codes and have one
>500 code.

I'd certainly prefer that to a proliferation of them if that's the only
choice. Especially since the 500 series has been misdocumented and/or
misimplement since their inception.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
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 08:35:18 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:50 EDT