Hi Priya, There's a good chance Eirik Bjørsnøs recently identified the root of the problem here:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1006267 He says "Setting the Content-Length to 0 on Tomcat 5.0.x effectively prevents any other headers or status coded being set because the response is considered to be committed according to the servlet spec." I think 5.5 suffers from the same issue, though 6.x does not. I can't see an easy way to change Restlet to fix this ... Jerome, Thierry, help? Eirik seemed to think that just changing the order of Restlet operations to work, but I can't think of a good way to defer setting the content length in these cases. - Rob On Mon, Jan 12, 2009 at 11:49 AM, Priya Matpadi <[email protected]> wrote: > > 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 > > <[email protected]>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 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1021950
