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).
>
