well let's debug it together in 10 days ;) that's going to be easier ;)
On 2012-11-06, at 14:00, Guido Chari <[email protected]> wrote: > Sorry for the late answer. > > > 2012/11/2 Camillo Bruni <[email protected]> > >> >> On 2012-11-01, at 15:58, Guido Chari <[email protected]> wrote: >> >>> Both tests succeed. >> >> grml, maybe squeaksource falls under the argentinian import restriction >> as some sort of luxury goods :P >> > > Jeje. I don't think so, but.... > > > >> >> Ok so another try with zinc? >> >> ZnClient new >> systemPolicy; >> url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; >> setAcceptEncodingGzip; >> beOneShot; >> get >> > > Failed. > > >> >> >> could there be a problem with zip support in your image/vm? >> Can you run all the Compression tests? >> >> > Have only zip tests and they are green. > > >> thanks >> cami >> >> > I'm starting to think this may be something strange proxy blocking for gzip > content but it would be extremely strange. > > Guido > > > >>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >>
