Thanks for taking the time to look into this. Cheers, Andrei On Thu, Mar 21, 2013 at 8:47 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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
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 !
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 ;-)
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill