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 <camillobruni@gmail.com>
could you try the following "benchmarks"
http://dev.nuclearrooster.com/2009/11/08/checking-gzipdeflate-server-respons...
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 <sven@stfx.eu> 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 <charig@gmail.com> 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 <camillobruni@gmail.com> 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 <charig@gmail.com> 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