James M Snell wrote: > > http://www.intertwingly.net/wiki/pie/PaceBetterHttpResponseCode > > #pragma section-numbers off > > == Abstract == > > (Protocol) > > The existing discussion of HTTP Response Codes in Section 5.5 is pretty > thin. This pace fattens it up a bit with a few shoulds and musts > pertaining to the support of redirection status codes and human readable > error descriptions > > == Status == > > Proposed > > == Rationale == > > The existing discussion of HTTP Response codes in the -05 draft does not > provide any useful information about the handling of response codes or > the reporting of human readable error situation information.
I don't agree with the first part of this (if you want useful information go and read the HTTP spec). The second part, human readable, isn't a requirement imho. > HTTP defines different classes of responses that indicate the sucess or > failure of an operation. HTTP status codes of the form 2xx signal a > successful request. HTTP status codes of the form 3xx signal that the > request should be redirected to a different specified endpoint. HTTP > status codes of the form 4xx signal that an incorrect request has been > received by the client. HTTP status codes of the form 5xx signal that > the server was unable to successfully complete the operation. > APP clients SHOULD be capable of following the redirections specified by > the 301 "Moved Permanently", 302 "Found", 304 "Not Modified", 305 "Use > Proxy", and 307 "Temporary Redirection" status codes. APP > implementations MAY choose to support the 303 "See Other" status code. Why echo what's in a normative spec? > HTTP responses specifying 4xx or 5xx status codes MUST include an entity > containing a human readable, natural language explanation of the error > situation. A standardized format for reporting the error situation is > not defined. -1. I think this might superset HTTP. And we're introducing extra design overhead on the back of this (like locales and i18n and parsable formats) cheers Bill
