Hi, setting the reuse timeout to 0 or making a one shot client does not help. But while googling I found the exact issue described on the Pharo issue tracker: https://pharo.fogbugz.com/f/cases/18588/
The proposed workaround also worked for me: ZnNetworkingUtils default socketStreamClass: SocketStream. Cheers, Uko > On 25 Dec 2017, at 05:42, Andrew Glynn <aglyn...@gmail.com> wrote: > > 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 > > > >
