Hi Sven,

yes `session:` would be the ideal solution.
But because it wasn't there (only getter) I wasn't sure whether this was a design decision - e.g. because sessions can't be reused.

Thanks!
Peter

On Tue, Nov 28, 2017 at 10:51 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Peter,

> On 28 Nov 2017, at 10:42, Peter Uhn��k <i.uhnak@gmail.com> wrote:
>
> Hi,
>
> I have a scenario where I need to login to some web app and then reuse the session/cookies in further requests.
>
> The basic approach (as presented in Enterprise Pharo book) works just fine
>
> client := ZnClient new.
>
> client
>�� �� �� ��url: 'http://example.com/login';
>�� �� �� ��formAt: 'username' put: 'john.doe@acme.com';
>�� �� �� ��formAt: 'password' put: 'trustno1';
>�� �� �� ��post.
>
> client
>�� �� �� ��get: 'http://example.com/my-file'.
>
> The problem is when I want to change the way response is retrieved. E.g.
>
> client
>�� �� �� ��accept: 'text/json';
>�� �� �� ��contentReader: [ :entity | STON fromString: entity contents ];
>�� �� �� ��get: 'http://example.com/some.json'.
>
> "uh-oh... it still uses STON contentReader"
> client
>�� �� �� ��get: 'http://example.com/homepage.html'
>
>
> Of course I could manually copy all the cookies, however I imagine there is a better approach. Maybe injecting session from one ZnClient instance to another?
>
> Thanks,
> Peter

Reusing a ZnClient makes most sense when you access one host in a uniform way.

Like you say, there are different options

��- reset the content reader when needed (assign nil)
��- make your content reader more intelligent (check the entity's content type and act accordingly)
��- get the #session from one client and use in on another one (#session: must be added for this)

ZnClient holds all kind of state (it is also a builder), so some occasional resetting (or managing this state) can be needed.

Does this help ?

Sven