I think the HTTP/1.1 Specification is pretty clear on what a successful response is. It states that response codes are extensible as well as stating that all 2XX codes are in the Success classification. Furthermore
"applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class" http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 -----Original Message----- From: Jonathan Hall [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 12:22 PM To: [email protected] Subject: Re: Bad implementation of Status error checking Hi Paul, It makes more sense to me to follow the specs strictly, especially from a web services point of view. The spec says that the "Success" codes are 200,201,202,203,204,205,206,207 (WebDAV - http://www.ietf.org/rfc/rfc2518.txt). 1xx are Informational (Meta) codes and 3xx Redirection codes and are therefore NOT Success codes. I have not come across a situation where I needed to use my own status code, so I do not know if you are prohibited in doing so. Though, this does sound like a useful feature. Jon Paul J. Lucas wrote: > Also, it seems that isSuccess() is wrong. In reading RFC 2616, 1xx > and 3xx codes are not errors, so they should be considered success > codes, no? > > - Paul > > > On Jan 16, 2008, at 10:09 AM, Paul J. Lucas wrote: > >> What if I want to make up my own Status codes? The isSuccess() and >> is*Error() methods do explicit code checks. Why? Why isn't the >> implementation for, say, isSuccess() this: >> >> return code >= 200 && code < 300; >> >> ? >
