Both tests succeed. I couldn't read at home so i couldn't test it without the proxy but i'm "almost sure" the proxy is not explaining the issue.
2012/11/1 Camillo Bruni <[email protected]> > could you try the following "benchmarks" > > > http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-responses-with-curl/ > > with the following urls (just 2 projects): > http://smalltalkhub.com/mc/estebanlm/Voyage/main > http://squeaksource.com/NativeBoost/ > > both support gzip answers without problems. > > On 2012-10-31, at 23:47, Sven Van Caekenberghe <[email protected]> wrote: > > Would it be possible to test without the transparant proxy ? > > From another location, like from home ? > > If this would fail for everyone, we would have heard about it much > sooner. > > > > On 31 Oct 2012, at 22:27, Guido Chari <[email protected]> wrote: > > > >> Yes, since a couple of weeks i can't. I'm on a Unix now behind a > transparent proxy. Same Vm, on same machine, behind the same proxy, no > problem if strip out the gzip header from the packet. > >> > >> I'm using a custom personalized VM. But the only thing that is > generating the error is the gzip header option on the http packet. Is that > option deeply related or coupled to the vm? BTW, the error is a 400 from > the server so i don't believe so. > >> > >> No one else experimenting the same as me? > >> > >> > >> > >> 2012/10/31 Camillo Bruni <[email protected]> > >> You say you cannot download from squeaksource in the latest 2.0 image? > >> > >> We use that regularly, for instance for the NativeBoost build, > >> and everything works fine (win / linux / mac) > >> > >> That leaves me quite puzzled about the real cause of this bug... > >> > >> > >> On 2012-10-31, at 21:47, Guido Chari <[email protected]> wrote: > >>> Hi, > >>> > >>> Since a couple of weeks i'm have not been able to download packages > with > >>> Metacello on last image versions from Jenkins. > >>> > >>> Today i found that if i revert changes on httpClient method from > >>> MCHttpRepository everything works fine again. > >>> > >>> I haven't research deeply on why, i'm not an expert on Zinc, but the > >>> message that is breaking everything and making my image to receive a > 400 > >>> error from squeaksource is setAcceptEncodingGzip that is addinng the > gzip > >>> header to the requests. > >>> > >>> As i said, i haven't going to deep with this but as i am the only one > who > >>> is watching this behavior perhaps is something only for squeaksource. > >>> > >>> If this is actually an issue and not some fault from myself, and > someone > >>> give me some help, i can help with the solution. > >>> > >>> Cheers, > >>> Guido. > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > > > > > >
