- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 20 Nov 1997 14:52:03 -0800
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Having a document to vet and register proposed status codes is a good idea -- one that we have discussed in the past. Reserving sets of status codes for use by other protocols is a bad idea. HTTP status codes need to be thought-out with the rigor of an RFC. The draft is insufficient for helping IANA set up a registry. Better examples of that are the charset and media type registries. HTTP/1.x status codes are three digits. Responses are examined for three digits. Any more than three digits and the response will be treated as HTTP/0.9. When a protocol using HTTP needs a new status code, it can talk about it in the abstract (e.g., 4aa) until a sufficient justification can be put in text and registered for that status. There is no need to pre-register codes that might be needed. Fewer than 10% of the proposals for new status codes have been accepted, usually because the authors didn't bother to check for an existing status code that already serves their purpose, or simply wanted their own "special" code "just in case", or the proposal faded into dust long before implementation. What other protocols not using HTTP want to do with their own status codes is not relevant. I suggest they use more than three digits. Likewise, it would make sense for HTTP/2+ to use more than three digits (or at least a token with wider range). ....Roy
Received on Thursday, 20 November 1997 15:38:18 UTC