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 <pdebruic@gmail.com> 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