The only time I've seen that behaviour is with the combination of a slow server
and a proxy such as CloudFlare where the sysadmin has set tcp_wait to some
ridiculously small number. Have you tried setting the connection reuse timeout
to 0, or setting 'beOneShot'?
Zinc doesn't support the additions in HTTP/2, but I can't offhand think of any
reason that should cause that specific behaviour. I've had sufficient problems
with HTTP/2 over slow connections (I live where there are no land lines of any
kind) that I replaced the HTTP/2 code in Nginx with code from pureftpd in order
to access my server at home when I'm out.
Andrew
On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk"
<pharo-users-boun...@lists.pharo.org on behalf of yuriy.tymc...@me.com> wrote:
Hi,
I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have
a simple REST API). When I try to do a GET request with Zinc like this:
ZnClient new
url:
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get
I get a “ConnectionClosed: Connection closed while waiting for data”
exception. The service provides a JSON response that I can get without a
problem by using a web browser or curl. Also if I try to access fewer data
(e.g. adding /1 to the url, so it gets only one resource) I don’t get the
exception.
What is even more strange, when I resume the exception I get the desired
response i.e. this works:
[ ZnClient new
url:
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get ]
on: ConnectionClosed
do: [ :ex |
ex resumeUnchecked: ex defaultResumeValue ]
Of course I cannot share the server that is on my local network for
resting, but maybe anyone knows it there are any known issues with Zinc, or if
there are ways for me to debug the issue further.
Cheers.
Uko
[1]: https://www.developers.meethue.com
