RE: Bad implementation of Status error checking
Hi all, Thanks for the clarification debate on status code classes. I have just fixed the issues in SVN trunk and closed the report: http://restlet.tigris.org/issues/show_bug.cgi?id=422 Best regards, Jerome -Message d'origine- De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 janvier 2008 05:26 À : discuss@restlet.tigris.org Objet : Re: Bad implementation of Status error checking The httpbis drafts mentioned in another thread clarify the intent of Berners-Lee, Fielding et al. in support of Paul's view: http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-sema ntics-01.txt (Expires July 15, 2008) HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, 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, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status. While this is not strictly canon yet, I think Restlet should track this clarified behavior. - Rob
Re: Bad implementation of Status error checking
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; ?
Re: Bad implementation of Status error checking
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. The behavior of intermediaries, such as forward and reverse proxies, would be undefined in relation to a custom status code, which could lead to some really difficult-to-find problems.
Re: Bad implementation of Status error checking
... That, plus what Joshua Tuberville quoted from RFC 2616: ... 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 Note the use of the word MUST. Hence, Restlet is NOT in compliance with the RFC. I would consider this a bug. After reading that bit of the RFC I agree. isSuccess() should return true for all 2xx. Also, for all other applicables. Jon
Re: Bad implementation of Status error checking
Perhaps, but that shouldn't be for you^D^D^DJerome to decree. Fixed that for ya. :-) In my case, we're dealing with a custom server and a custom client that talk only to each other. Then my comment about intermediaries obviously does not apply to your case. Custom HTTP status codes should be avoided in the wild where they may confuse proxies and UAs whose authors may not have read the spec very carefully, of which there are regrettably many. That, plus what Joshua Tuberville quoted from RFC 2616: ... 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 Note the use of the word MUST. Hence, Restlet is NOT in compliance with the RFC. I would consider this a bug. Yes, I believe you are right, please file it if you have not done so already. I don't know that it would be intuitive for isSuccess to be true for 1xx or 3xx. I think of the success codes as the 2xx series exclusively (cf. the language previously cited). - R
Re: Bad implementation of Status error checking
The httpbis drafts mentioned in another thread clarify the intent of Berners-Lee, Fielding et al. in support of Paul's view: http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-01.txt(Expires July 15, 2008) HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, 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, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status. While this is not strictly canon yet, I think Restlet should track this clarified behavior. - Rob
