Hi Sven, No, I’m on Mac (OS 10.13).
Cheers. Uko > On 25 Dec 2017, at 20:03, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > >> On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymc...@me.com> wrote: >> >> 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. > > You are on Windows I guess ? > >> 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 >>> >>> >>> >>> >> >> > >
