On Thu, Mar 21, 2013 at 4:47 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > On 21 Mar 2013, at 14:52, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 21 Mar 2013, at 14:37, Andrei Vasile Chis <chisvasileand...@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 ;-) > > wow....what a great catch. Thanks Sven for all your hard and excellent work!!! > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > -- Mariano http://marianopeck.wordpress.com
