Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing a "chunked" ZnResponse on a stream raises "Improper store into indexable objects" #33

Open
bocasti opened this issue Apr 8, 2019 · 4 comments

Comments

@bocasti
Copy link

bocasti commented Apr 8, 2019

Issue can be reproduced with a Pharo 7 image.
Here is a piece of code to reproduce:

znResponse := 	(ZnResponse statusCode: 400)
						entity: (ZnEntity with: '{"error": "invalid_token","error_description":"Access Token is invalid."}' type: ZnMimeType applicationJson); yourself.
znResponse headers at: 'Transfer-Encoding' put: 'chunked'.
						
String streamContents: [:stream | znResponse writeOn: stream ].

I have the feeling that the Zinc encoder is expected to work with a "bivalent" stream,
So that it can optimize and directly write bytes (see #next:putAllASCII:startingAt:toStream:).

In the example above, the encoder is used with a ZnBufferedWriteStream.
And writing bytes on such stream raises the exception.

I am able to workaround by making a change like this one:

ZnEntityWriter >> writeEntity: entity
	...
	actualStream := ZnBivalentWriteStream on: actualStream.
	entity writeOn: actualStream.
	...

@svenvc
Copy link
Owner

svenvc commented Apr 8, 2019

Hi,

Thanks for reaching out and reporting your problem with an executable snippet.

However (and I do not known if this is related to the snippet or your original issue), ZnMessages are meant to be written to and read from binary socket streams (and yes they also use some bivalent tricks).

So your example works with

ByteArray streamContents: [:stream | znResponse writeOn: stream ].

But maybe that does not help ...

Sven

@bocasti
Copy link
Author

bocasti commented Apr 8, 2019

Yes, that does help, thank you.
Then it means that we were wrongly using #writeOn: as a kind of "string printing utility" method.
And I guess it was working in some cases and not in some other.

@svenvc
Copy link
Owner

svenvc commented Apr 8, 2019

Yes, exactly, it works in some cases, but not all.

You know about ZnLogEvent ? Try:

ZnLogEvent open

and use GT inspector to follow the announcements tab, you'll get real event objects that you can inspect.

@bocasti
Copy link
Author

bocasti commented Apr 8, 2019

Didn't know, thank you.
Here the objective was not to debug "live",
but rather to log (outside the image) comprehensive representation (status, header, entity) of some response we get.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants