RE: Re: Re: Tomcat appears to swallow Allow: header
Hi Rob,
That is really weird, I've checked the again code in branch 1.1 and in trunk :
both are identical. The changes were only made in the
ServletCall#sendResponse() method.
I would suggest to double check that your 1.1 build does contain the fix or to
trace it down manually. Let me know!
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Rob Heittman [mailto:rob.heitt...@solertium.com]
Envoye : lundi 19 janvier 2009 01:46
A : discuss@restlet.tigris.org
Objet : Re: Re: Re: Tomcat appears to swallow Allow: header
Hi, Jerome!
Turns out that, while 1.2 snapshot *does* fix the issue in GWT and
Tomcat 5, 1.1 snapshot *does not* fix it. I'm at a bit of a loss as
to how to troubleshoot beyond that. Where was the change mainly
applied?
- R
On Wed, Jan 14, 2009 at 7:51 AM, Jerome Louvel
wrote:
> Awesome!! The fix has been apply to the 1.1 branch in SVN. Thanks Rob for
> testing this.
>
> Thierry has fixed the redirect issue. FYI, there is a browsable directory
> with all the releases available. Useful if you need a
> snapshot of 1.1 branch :-)
> http://www.restlet.org/downloads/archives
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Rob Heittman [mailto:rob.heitt...@solertium.com]
> Envoye : mercredi 14 janvier 2009 02:41
> A : discuss@restlet.tigris.org
> Objet : Re: Re: Re: Tomcat appears to swallow Allow: header
>
> Much weeping and gnashing of teeth later ... I took out the entity
> hacks from GoGoEgo, ran on Restlet 1.1, observed the Tomcat problems
> under GWT hosted mode, ported to Restlet 1.2 snapshot, took out the
> entity hacks, and am not seeing the adverse behavior. Barring a more
> scientific analysis ... I think this fix really solves the problem!
> Sweet!
>
> Unrelated - did you know that when you download snapshot ("development
> version - unstable") from www.restlet.org/downloads you get redirected
> to the 1.1 snapshot? This is a bit confusing :-) I had to guess the
> URL for the 1.2 snapshot.
>
> On Tue, Jan 13, 2009 at 5:31 PM, Jerome Louvel
> wrote:
>> The latest snapshot (Restlet 1.2) already contains the fix:
>> http://www.restlet.org/documentation/snapshot/changes
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023299
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024085
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1033522
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1039028
Re: Re: Re: Tomcat appears to swallow Allow: header
Hi, Jerome!
Turns out that, while 1.2 snapshot *does* fix the issue in GWT and
Tomcat 5, 1.1 snapshot *does not* fix it. I'm at a bit of a loss as
to how to troubleshoot beyond that. Where was the change mainly
applied?
- R
On Wed, Jan 14, 2009 at 7:51 AM, Jerome Louvel
wrote:
> Awesome!! The fix has been apply to the 1.1 branch in SVN. Thanks Rob for
> testing this.
>
> Thierry has fixed the redirect issue. FYI, there is a browsable directory
> with all the releases available. Useful if you need a
> snapshot of 1.1 branch :-)
> http://www.restlet.org/downloads/archives
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-
> De : Rob Heittman [mailto:rob.heitt...@solertium.com]
> Envoye : mercredi 14 janvier 2009 02:41
> A : discuss@restlet.tigris.org
> Objet : Re: Re: Re: Tomcat appears to swallow Allow: header
>
> Much weeping and gnashing of teeth later ... I took out the entity
> hacks from GoGoEgo, ran on Restlet 1.1, observed the Tomcat problems
> under GWT hosted mode, ported to Restlet 1.2 snapshot, took out the
> entity hacks, and am not seeing the adverse behavior. Barring a more
> scientific analysis ... I think this fix really solves the problem!
> Sweet!
>
> Unrelated - did you know that when you download snapshot ("development
> version - unstable") from www.restlet.org/downloads you get redirected
> to the 1.1 snapshot? This is a bit confusing :-) I had to guess the
> URL for the 1.2 snapshot.
>
> On Tue, Jan 13, 2009 at 5:31 PM, Jerome Louvel
> wrote:
>> The latest snapshot (Restlet 1.2) already contains the fix:
>> http://www.restlet.org/documentation/snapshot/changes
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023299
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024085
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1033522
Re: Re: Re: Tomcat appears to swallow Allow: header
Which I do! I will switch our GoGoEgo dependencies to use the 1.1 branch snapshot so we can drop the hacks. On Wed, Jan 14, 2009 at 7:51 AM, Jerome Louvel wrote: > Thierry has fixed the redirect issue. FYI, there is a browsable directory > with all the releases available. Useful if you need a > snapshot of 1.1 branch :-) > http://www.restlet.org/downloads/archives -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024091
RE: Re: Re: Tomcat appears to swallow Allow: header
Awesome!! The fix has been apply to the 1.1 branch in SVN. Thanks Rob for
testing this.
Thierry has fixed the redirect issue. FYI, there is a browsable directory with
all the releases available. Useful if you need a
snapshot of 1.1 branch :-)
http://www.restlet.org/downloads/archives
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Rob Heittman [mailto:rob.heitt...@solertium.com]
Envoye : mercredi 14 janvier 2009 02:41
A : discuss@restlet.tigris.org
Objet : Re: Re: Re: Tomcat appears to swallow Allow: header
Much weeping and gnashing of teeth later ... I took out the entity
hacks from GoGoEgo, ran on Restlet 1.1, observed the Tomcat problems
under GWT hosted mode, ported to Restlet 1.2 snapshot, took out the
entity hacks, and am not seeing the adverse behavior. Barring a more
scientific analysis ... I think this fix really solves the problem!
Sweet!
Unrelated - did you know that when you download snapshot ("development
version - unstable") from www.restlet.org/downloads you get redirected
to the 1.1 snapshot? This is a bit confusing :-) I had to guess the
URL for the 1.2 snapshot.
On Tue, Jan 13, 2009 at 5:31 PM, Jerome Louvel
wrote:
> The latest snapshot (Restlet 1.2) already contains the fix:
> http://www.restlet.org/documentation/snapshot/changes
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023299
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1024085
Re: Re: Re: Tomcat appears to swallow Allow: header
Much weeping and gnashing of teeth later ... I took out the entity
hacks from GoGoEgo, ran on Restlet 1.1, observed the Tomcat problems
under GWT hosted mode, ported to Restlet 1.2 snapshot, took out the
entity hacks, and am not seeing the adverse behavior. Barring a more
scientific analysis ... I think this fix really solves the problem!
Sweet!
Unrelated - did you know that when you download snapshot ("development
version - unstable") from www.restlet.org/downloads you get redirected
to the 1.1 snapshot? This is a bit confusing :-) I had to guess the
URL for the 1.2 snapshot.
On Tue, Jan 13, 2009 at 5:31 PM, Jerome Louvel
wrote:
> The latest snapshot (Restlet 1.2) already contains the fix:
> http://www.restlet.org/documentation/snapshot/changes
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1023299
RE: Re: Re: Tomcat appears to swallow Allow: header
Hi all, I haven't ported the fix to Restlet 1.1 yet. I would like to get more feed-back on SVN trunk first due to potential impact if this approach has flaws. The latest snapshot (Restlet 1.2) already contains the fix: http://www.restlet.org/documentation/snapshot/changes It can be downloaded from this page: http://www.restlet.org/downloads/ Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : Rob Heittman [mailto:rob.heitt...@solertium.com] Envoye : mardi 13 janvier 2009 23:17 A : discuss@restlet.tigris.org Objet : Re: Re: Re: Tomcat appears to swallow Allow: header Jerome committed a candidate fix to trunk today and mentioned it in the previously referenced thread. I can't test it until tomorrow, but if you can build trunk or use tomorrow's snapshot, you may be able to verify the fix before I can. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022985
Re: Re: Re: Tomcat appears to swallow Allow: header
Jerome committed a candidate fix to trunk today and mentioned it in the previously referenced thread. I can't test it until tomorrow, but if you can build trunk or use tomorrow's snapshot, you may be able to verify the fix before I can. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022966
RE: Re: Re: Tomcat appears to swallow Allow: header
Well, I compared HttpServerConverter#commit code in restlet 1.0.10 and restlet
1.1.1, and the 1.0.10 version did not check for content length or response code
before adding the headers. Surely this needs to be fixed in restlet 1.1.1.
HttpServerConverter#commit code in restlet 1.0.10 was as follows:
public void commit(HttpResponse response) {
try {
// Add the response headers
addResponseHeaders(response);
// Send the response to the client
response.getHttpCall().sendResponse(response);
} catch (Exception e) {
getLogger().log(Level.INFO, "Exception intercepted", e);
response.getHttpCall().setStatusCode(Status.SERVER_ERROR_INTERNAL.getCode());
response.getHttpCall().setReasonPhrase(
"An unexpected exception occured");
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022684
Re: Re: Tomcat appears to swallow Allow: header
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 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
> > 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
RE: Re: Tomcat appears to swallow Allow: header
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
> 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
