: 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
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()
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
... 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,
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
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
6 matches
Mail list logo
