Andrei was very helpful in giving me remote access to a machine with a Pharo 2.0 image running inside their network, so that I could have a look at his problem myself - Thanks Andrei !
On 21 Mar 2013, at 14:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
> On 21 Mar 2013, at 14:37, Andrei Vasile Chis <chisvasileandrei@gmail.com> wrote:
>
>> I will check, however it happes for a lot of packages.
>> Some work, and some do not work.
>
> Strange, I don't think it has to do with the contents, the MC unzipping has not yet even happened.
> Maybe the size is an element (chunking, buffering).
>
>> @Sven I have a linux installation on virtual box where I could reproduce this problem.
>> I can give you access to it.
>
> OK, continuing off list.
>
> Sven
I think I finally found the cause of this mysterious bug.
The bug only appears when ZnEntityReader>>#readEntityFromStream needs to read a GZIP compressed response without an explicit Content-Length (so that it has to read up to end - pretty rare, apparently more common in the case of certain proxies) for a total size less than 65536 bytes (that is why it didn't happen on all cases ;-).
In these particular circumstances, a GZipReadStream was created directly on top of a raw SocketStream, which immediately sends a #next: 65536 to the SocketStream. Which fails with a ConnectionClosed instead of returning just the available bytes (like #upToEnd).
The fix depends on the question which method is actually wrong, the subject of my next mail ;-)