Hi Arjohn, Thanks for reporting this problem. You are touching an edge but important case that we need to better address.
The decision currently made to switch to a 204 status is based on the Representation#isAvailable() method, which considers an empty representation (size == 0) as non-available. As you explained this isn't quite right. To get us started in a better directory, I have added Representation#isEmpty() and hasKnownSize() method in SVN trunk (upcoming 2.1 RC1). Best regards, Jerome -- http://www.restlet.org http://twitter.com/#!/jlouvel -----Message d'origine----- De : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] Envoyé : lundi 3 octobre 2011 15:12 À : discuss@restlet.tigris.org Objet : 204 results instead of empty strings Related to my previous question regarding empty string parameter values: I have written a server resource that returns String values. The DefaultConverter takes care of converting this to/from a text/plain representation. The restlet framework does a brilliant job at taking care of all this, except when the result is an empty string. In this case, restlet returns a 204 "no content" result. While the 204 result might look accurate, it doesn't look semantically correct to me. There's a difference between "no content" and "empty content". RFC 2616 says the following about 204 codes: "... If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent..." So, in a browser, you'll never see the empty result. The request appears to be ignored instead. On the client resource side, the 204 response is converted to a <null> value, rather than an empty string. This requires me to add a null-check in all client resources that return Strings. Any thoughts on this? Regards, Arjohn Kampman ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=28494 37 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2850281