Hey Sven, Thanks for the response! By tracing, I also just noticed that our webserver returned 'text/plain' mimetype instead of a binary one.
It was our fault. Zinc is cool, just too bad it exposed our errors now ;-) Cheers! Johan On 06 Apr 2012, at 09:41, Sven Van Caekenberghe wrote: > Dag Johan, > > On 06 Apr 2012, at 08:58, Johan Brichau wrote: > >> Hi everyone, >> >> I'm test-driving Pharo 1.4 beta and I'm getting an error loading any package >> from our webdav-based monticello repository. >> The error surfaces in the reading of the zipfile by monticello, but it seems >> the source of the problems is the replacement of sockets by Zinc sockets: >> >> It seems that Zinc's "get" returns a ByteString instance when getting the >> file (in method MCHttpRepository>>#readStreamForFileNamed:do:) from the >> webdav volume. In contrast, when I'm loading a package from squeaksource, it >> returns a ByteArray. >> >> The reading of the zip goes wrong because the stream is returning characters >> instead of bytes. So I guess the difference between the ByteString and the >> ByteArray is the source of that problem. >> >> Maybe anyone knows why this happens? >> In the meantime... I'm digging deeper >> >> Johan > > Yes, this sounds familiar: Zn is much more strict at the HTTP level, most > probably your server returns a text mime-type. Hence Zn interprets this as a > string. Take one of your packages' URLs and do: > > ZnEasy get: 'http://my-web-dav/repo/Code.123.mcz'. > > and inspect the results, you'll see the mime type there. Compare it to, for > example: > > ZnEasy get: > 'http://mc.stfx.eu/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.254.mcz' > > The solution is to fix your server to use any binary mime-type for .mcz files > (application/octet-stream or even application/x-monticello). > > Sven > > PS: Zinc does not 'replace sockets', it is an HTTP client using regular > socket[streams].
