: 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
applie
.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
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
>
s.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 seein
Hi Rob,
thanks for your report. The snapshot is now redirected to the 1.2
snapshot...
best regards,
Thierry Boileau
> 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 Res
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
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
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:
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 foll
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
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 i
gt;
> --
> *De :* Rob Heittman [mailto:[EMAIL PROTECTED]
> *Envoyé :* vendredi 5 septembre 2008 21:49
> *À :* discuss@restlet.tigris.org
> *Objet :* Re: Tomcat appears to swallow Allow: header
>
> I identified the problem: Tomcat is not properly ret
:[EMAIL PROTECTED]
Envoyé : vendredi 5 septembre 2008 21:49
À : discuss@restlet.tigris.org
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
respo
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 th
Just noticed something bizarre in tracking down a WebDAV bug report.
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
Hi John,
you're right, something is missing. The implemented handlers have to update
the "ALLOW" header in the response each time they are requested but are
unable to do so. I'm not sure the Rest API should change (Handler class is
part of the Rest API) but at least the i
the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
Note the last sentence about the requirement of returning an Allow header.
No, I never noticed that before either. :-) But it looks like Handler
should support that.
Hope this helps,
John
t; Envoyé : lundi 9 octobre 2006 11:15
> À : discuss@restlet.tigris.org
> Objet : Re: Breaking Call into Request and Response (Was:
> Allow Header)
>
> Been thinking over the weekend on this issue. I rather like the call
> interface. It is a unified and well encapsulated entity.
>
>
Hi Lars,
Thanks for the testing, I appreciate!
Best regards,
Jerome
> -Message d'origine-
> De : Lars Heuer [mailto:[EMAIL PROTECTED]
> Envoyé : samedi 7 octobre 2006 15:50
> À : Jerome Louvel
> Objet : Re: Breaking Call into Request and Response (Was:
>
Been thinking over the weekend on this issue. I rather like the call
interface. It is a unified and well encapsulated entity.
How about keeping the Restlets "handle(Call)" as is and let it
extract the request and response objects as and when it requires?
Call.getRequest()
Call.getResponse()
So
Hi Jerome,
[...]
> Testing over the week-end is very welcome as I'll try to finish/release on
> Monday if possible.
Last night I converted two projects to the new Request/Response style
and everything works as expected.
Best regards,
Lars
--
http://www.semagia.com
Hi Jerome,
Jerome Louvel noelios.com> writes:
>
> Hi Sean,
>
> I've just checked in SVN the modification for Call split and Allow support.
> All unit tests pass but I haven't done thorough testing. Also Servlet
> adapter is still broken.
My work depends on the Servlet adapter but I wouldn't b
.
Best regards,
Jerome
> -Message d'origine-
> De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis
> Envoyé : vendredi 6 octobre 2006 00:24
> À : discuss@restlet.tigris.org
> Objet : Re: Breaking Call into Request and Response (Was:
> Allow Header)
&
Jerome Louvel noelios.com> writes:
>
>
> Hi all,
>
> I share the same concern as Piyush. There are now about 34 methods in the
> Call class, corresponding to about 20 properties.
...
> If there is no major opposition, I will try to integrate this change to beta
> 19. Any comment?
>
I'm tor
t; De : Piyush Purang [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 5 octobre 2006 19:04
> À : discuss@restlet.tigris.org
> Objet : Re: Breaking Call into Request and Response (Was:
> Allow Header)
>
> Hi Jerome,
>
> +1
>
> As usual I will keep the final word till I ha
Hi Jerome,
+1
As usual I will keep the final word till I have already used the
refactorings...
Bugger I have to change all that code again.. did I just ask for all
those changes... what extent we go for apparent improvements :)
Do you have a deadline in mind for the b19? I think many are wait
gt; For the time being I'll comment out the respective line in
> HttpServerConverter to set my Allow header
Okie.
Best regards,
Jerome
> -Message d'origine-
> De : Lars Heuer [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 5 octobre 2006 15:19
> À : Jerome Louvel
>
opposition, I will try to integrate this change to beta
19. Any comment?
Best regards,
Jerome
> -Message d'origine-
> De : Piyush Purang [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 5 octobre 2006 15:10
> À : discuss@restlet.tigris.org
> Objet : Re: Allow Header
>
[...]
> Because it is more a "server thing", I don't know if the
> call.getAllowedMethods() makes sense. The idea with the additional
Arrg, sorry, I am thinking too server-centric. It makes sense on the
client side of course. :)
Best regards,
Lars
--
http://www.semagia.com
;server thing", I don't know if the
call.getAllowedMethods() makes sense. The idea with the additional
methods on "Resource" sounds good.
Do you have a timeline for it? Will it be in b19?
For the time being I'll comment out the respective line in
HttpServerConverter to set my Allow header
Best regards,
Lars
--
http://www.semagia.com
My immediate concern is a Call object with an ever increasing
interface. As of last count (b18) it stands at 30+ methods.
octobre 2006 14:18
> À : Jerome Louvel
> Objet : Re: Allow Header
>
> Hi Jerome,
>
> > Only non-standard headers can be added via the special
> attribute. The
> > "Allow" header is supported at the API level by the
> > Call.getClient().getAccepted
Hi Jerome,
> Only non-standard headers can be added via the special attribute. The
> "Allow" header is supported at the API level by the
> Call.getClient().getAccepted*() methods.
Thanks, that was one of the places where I looked, but I cannot find a
way how to set, i.e.
Hi Lars,
Only non-standard headers can be added via the special attribute. The
"Allow" header is supported at the API level by the
Call.getClient().getAccepted*() methods.
Best regards,
Jerome
> -Message d'origine-
> De : Lars Heuer [mailto:[EMAIL PROTECTED
Hi all,
How can I set the HTTP header "Allow"? If I use the new
call.getAttributes(...) method Restlet tells me, that I cannot set the
"Allow" header.
Best regards,
Lars
--
http://www.semagia.com
35 matches
Mail list logo
