RE: Bad implementation of Status error checking

2008-01-21 Thread Jerome Louvel
] > 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: >

Re: Bad implementation of Status error checking

2008-01-16 Thread Rob Heittman
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

Re: Bad implementation of Status error checking

2008-01-16 Thread Rob Heittman
> > 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 shou

Re: Bad implementation of Status error checking

2008-01-16 Thread Jonathan Hall
... 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, Restl

Re: Bad implementation of Status error checking

2008-01-16 Thread Paul J. Lucas
On Jan 16, 2008, at 12:43 PM, Rob Heittman wrote: 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. Perhaps, but that shouldn't be for you to decree. If a

Re: Bad implementation of Status error checking

2008-01-16 Thread Rob Heittman
> > 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

RE: Bad implementation of Status error checking

2008-01-16 Thread Joshua Tuberville
2:22 PM To: discuss@restlet.tigris.org 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 -

Re: Bad implementation of Status error checking

2008-01-16 Thread Jonathan Hall
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 c

Re: Bad implementation of Status error checking

2008-01-16 Thread Paul J. Lucas
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() metho

Bad implementation of Status error checking

2008-01-16 Thread Paul J. Lucas
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; ? - Paul P.S.: And the boolean 'result' variable is so unnecessary.