Hi Paul,
Your analysis is correct: #resetEntity is (by default) only called before
executing HEAD and DELETE methods and not (by default) before a GET (nor a PUT
or POST).
The reason is that ZnClient is (also) a builder to construct requests. One of
the features of the builder is that it lets you do multiple requests to the
same server (or resource) where you might have lots of options configured. It
also lets you build up the entity that you want to sent along.
More specifically, HTML forms using an applicationFormUrlEncodedEntity and a
GET are supported through #formAt:* - see for example #testGetForm.
The issue you raised is the consequence of preferring the latter as a
works-out-of-the-box vs. your surprise it-sends-and-older-entity with a GET. I
can't immediately see how to solve both by default.
Both manually calling #resetEntity or configuring #autoResetEntityMethods: are
options/solutions.
For example, here is how my main/internal API client sets up its re-usable
ZnClient instance:
setUpHttpClient
^ ZnClient new
clientId: 'T3clnt';
host: self connectionSpec host;
port: self connectionSpec port;
accept: ZnMimeType applicationJson;
logLevel: 2;
enforceAcceptContentType: true;
autoResetEntityMethods: #(#HEAD #DELETE #GET);
contentReader: [ :entity | self parseJson: entity ];
contentWriter: [ :data | self asJsonEntity: data ];
yourself
I change the reset entity default because I know I never use the form option.
HTH,
Sven
> On 16 Jan 2018, at 01:47, PAUL DEBRUICKER <[email protected]> wrote:
>
>
> Hi -
>
> Should #resetEntity be called automatically for long lived sessions ? I see
> that it is called automatically for HEAD and DELETE methods.
>
>
> If you do a
>
> |client |
> client:=ZnClient new.
> client get: 'http://example.com/getPath'
> client inspect
> client post: 'http://example.com' contents:'My Contents'
> client inspect.
> client get: 'http://example.com/getPath'
> client inspect.
> client close.
>
>
> and then look at the changed headers between the first and last GET you can
> see that the body from the POST was sent in the 2nd GET request. I can't
> think of a time when you'd want that, generally.
>
> Maybe it would be better to make keeping the entity around as the exception
> in all cases and ask for it specifically when you want it. I'm not sure of
> the answer I was just surprised by the behavior and can definitely send
> #resetEntity for my use case.
>
>
> Paul
