Hello all,
as it is a good idea, I've entered the issue 420 for that point.
http://restlet.tigris.org/issues/show_bug.cgi?id=420
best regards,
Thierry Boileau
On Jan 14, 2008 7:59 PM, Paul J. Lucas [EMAIL PROTECTED] wrote:
On Jan 14, 2008, at 10:49 AM, Valdis Rigdon wrote:
Why does it have
Jerome Louvel contact at noelios.com writes:
Hi Jason,
Thanks for the report.
The current WAR client has not been fully tested and should be considered
alpha code. We plan to have full WAR protocol support in 1.1 M3 only, with
a consistent behavior between Servlet and standalone modes.
Sounds good!
Thanks,
Avi
--
Avi Flax » Partner » Arc90 » http://arc90.com
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
Hi Davide and Avi,
It seems related to the save/load representations via variables that we
discussed previously. We should be able to load an XML representation from a
file, or save from a previous GET request and so send it via a POST
afterwards.
Best regards,
Jerome
-Message
... 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
Someone might consider putting this question to the people doing the
2616bis update to HTTP. See
http://www.ietf.org/html.charters/httpbis-charter.html - there is a
mailing list.
As I understand it, part of their charter is to clarify some of the
murkier pieces of the spec; this sounds like it
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
Awesome. I didn't know this effort existed. I did not see that they have
already cleared up this point in the drafts, although they did shed light on
the Status code issue in another thread.
I'll join the list ... this is stuff we should stay abreast of.
- R
11 matches
Mail list logo
