Re: GWT Accept header leak
Hello, thanks for reporting this issue (in the discussion list and in github). The fix is available in the current snapshot, and will be part of 2.1rc6 to be published soon. Best regards, Thierry Boileau I'm having a problem with a GWT client. If I have a proxy, which I call > repeatedly to poll a resource, each new request seems to add to the > existing Accept header, so I end up with requests like this: > > Accept: application/x-java-serialized-object+gwt, > application/x-java-serialized-object+gwt, > application/x-java-serialized-object+gwt, ... > > Eventually the server fails with a 413 error. It seems like this is a bug > with the Restlet GWT client if you call the same client proxy multiple > times. > > I'm using 2.1 rc5. > > -- > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2994486 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2998413
Re: Re: Re: Repeated calls by Restlet client to Restlet server hangs
Hello Jon,
from what I notice, this is due to the fact that the entity is not
consumed. I've just reproduced it using this code:
ClientResource cr = new
ClientResource("http://www.example.com";);
for (int i = 0; i < 20; i++) {
System.out.println(i);
cr.get();
}
After thinking more to your suggestion, I think there would be cases where
errors responses (404, or authentication errors), contain valuable
entities, that the client code would like to consume. Then I think we can't
factorise the code and just abort the connection in all cases.
I wonder if in your case, it is easier to add a "cr.release();" call which
takes care of "closing" the connection, just as you tried. As it must work
properly, and because I didn't reproduced this issue, could you provide a
sample test case?
Regarding the handling of exceptions, we have to think about it. The idea
is that this common code should handle properly exceptions issued from the
HttpClient apache library. I keep the issue open.
Please feel free to add any comment!
Best regards,
Thierry Boileau
Thierry,
>
> I have come up with a "fix" that solves the issue for us... but I don't
> know if it is the best/right solution. It doesn't seem to be the right way
> to handle it.
>
>
> I'm using the 2.0.11 source.
>
> In HttpMethodCall.sendRequest(Request) I noticed that after:
>
> this.httpResponse = this.clientHelper.getHttpClient().execute(
> getHttpRequest());
>
> when catching the exception they do this:
>
> // Release the connection
> getHttpRequest().abort();
>
> So in the non-exception case I added a test:
>
> if (result.isError()) {
> getHttpRequest().abort();
> }
>
> It seems odd to me that this code should have to know to abort the request
> in these error & exception cases, but not in the successful case. I also
> wonder if there are other exceptions (e.g. ClientProtocolException) that
> should be caught and handled similarly.
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2994842
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2998412
Re: Re: Re: Parameters for annotated resources with interface?
Hello Norm,
the API proposed by the Restlet framework is quite distinct than, let's
say, the jaxrs one. Especially regarding the handling of query parameters
and request's entity.
At first, there is a big wall between URIs that identify a resource, and
the request's entities wich is, in case of a PUT requests represents the
new state of the target resource.
According to the specification, the query part of the URL combines two
aspects : it is still part of the resource's identifier, and it can be read
a set of parameters.
Using the Restlet framework, another kind of "parameters" can be read from
the URIs : they are located in the path of the URL, and are defined using
the "routing" API of the framework. The following instruction defines a URI
template which contains one parameter called "id" :
router.attach("/account/{id}", AccountServerResource.class);
This URI template allows the framework to define a new route, and to
correctly transmit the control to the right resource at runtime.
Query parameters can be accessed using the resource' reference or directly
using some shortcuts (ServerResource#getQuery, for example), URIs
parameters are accessed, as said Tim, using the
ServerResource#getRequestAttributes method.
As also said Tim, the support of annotations in the Restlet framework can
be seen as a way to define Java method synonyms to technical HTTP methods,
with an important constraint: by design, there could be at most one
parameter which represents the request's entity (as a simple Representation
object, or as a deserialized customized object). The provided set of
annotations helps to link Java methods with HTTP ones, and annotation
parameters add a level of automation using the media type of the request
and/or response entity. The idea is that, when the ServerResource class is
instantiated and the "ServerResource#doInit" is invoked, you can get all
the "parameters" taken from the URI that identify the resource and check if
the resource really exists (there is a ServerResource#setExisting method),
or not, without considering any other aspects of the request. Then, the
request's entity is taken into consideration.
I hope this will give you a little bit more of explanations.
Best regards,
Thierry Boileau
Thanks Tim!
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2996980
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2998392
