Since the Restlet code all looks good to you, I'll package a test case in a WAR and try it out on some other Servlet app servers, like current Tomcat trunk, then report to whoever seems appropriate and cross-track it with a Restlet bug entry.
On Sun, Sep 14, 2008 at 7:52 AM, Jerome Louvel <[EMAIL PROTECTED]>wrote: > Hi Rob, > > That was new to me, thanks for bringing that to our attention as it might > be a common issue. > > It would help to ask to Tomcat team about the reasons of this behavior. > AFAICT, the Restlet/Servlet mapping looks fine, I'm not aware about any such > restriction in Servlet API, regarding absence of entity. > > Any other thought? > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > ------------------------------ > *De :* Rob Heittman [mailto:[EMAIL PROTECTED] > *Envoyé :* vendredi 5 septembre 2008 21:49 > *À :* [email protected] > *Objet :* Re: Tomcat appears to swallow Allow: header > > 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). >> > >
