I have successfully used restlet 1.0.10 with tomcat (5.5) container. I have
services that return 204 on HTTP POST and PUT, no content in body, but they
return cookies as set in the restlet response object.
When I upgraded to restlet 1.1.1, I found problems in the restlet framework
mapping restlet response to tomcat 5.5 httpservletresponse for services that
return 204 response code. This mapping is silently failing, we always get a
response code of 200 and the headers (including cookies) get lost. Note that
the LogFilter accurately displays that service returns 204, but with tomcat
request dumper valve enabled I verified that tomcat neither gets this response
code nor the headers.
I followed Rob’s suggestion, and added a dummy entity with a 204 response code.
getResponse().setEntity(new StringRepresentation("This entity is
not changed", MediaType.TEXT_PLAIN));
getResponse().setStatus(Status.SUCCESS_NO_CONTENT);
And voila, the response comes out with a 204 response code with the headers as
expected. Also, as expected the dummy entity gets stripped out.
We use jetty for development environment only, and this is not reproducible
with jetty. However, we are seeing this issue only with restlet 1.1.1. We have
not changed our tomcat version or settings.
This behavior is really bizarre. We know that the dummy entity gets stripped
out in HttpServerConverter.commit(); then it is not making sense to me as to
why setting dummy entity in the response is a fix.
> I identified the problem: Tomcat is not properly returning Responses with no
> entity. The two acute places this is obvious is with 304 Not Modified
> responses and with the OPTIONS response. Tomcat returns a 200 OK with some
> default headers, instead of passing the correct header set and no entity
> emerging from Restlet.
>
> I verified that the version of Tomcat embedded in GWT 1.4 exhibits the
> problem, but haven't yet verified it in other places.
>
> The workaround (which will cause Restlet 1.1 to gripe, but works) is to emit
> an entity anyway, when none is called for, e.g. new
> StringRepresentation("This entity is not changed",MediaType.TEXT_HTML); In
> my application, I keyed this to a system property so that the non-compliant
> behavior can be turned on only when needed.
>
> Someone who is more knowledgeable than I am about the Servlet extension may
> be able to figure out if this is a Restlet bug or not.
>
> On Wed, Sep 3, 2008 at 3:56 PM, Rob Heittman
> <rob.heitt...@solertium.com>wrote:
>
> > In some cases Tomcat appears to swallow the Allow: header that leaves
> > Restlet in response to an OPTIONS request. The Allow: header of the
> > response is populated, and I tracked it all the way down through ServletCall
> > and verified Restlet is doing the right thing. But, the OPTIONS response
> > sent to the client from Tomcat is stripped of this and other useful headers
> > (like DAV: 1,2).
> >
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1019528
