On 21 Mar 2013, at 22:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-03-21, at 20:47, 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 ;-).
yes I think that's how far I came as well :)
Sure, you and I were looking at the same spot before, but actually being in the debugger made all the difference. BTW, AFAIK it was Andrei who figured out that proceeding from the exception actually produced a correct result. I really had to 'see' this to believe it. And even then it took some quiet thinking to understand the issue.
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 ;-)
awesome! thanks for the nailing that one down! :)