Hi Stuart, On 03 Jun 2012, at 03:41, Stuart Herring wrote:
Hi all,
I recently ran into the problem with a server returning text/plain instead of application/octet stream again (see http://lists.gforge.inria.fr/pipermail/pharo-project/2012-April/062388.html), but the resulting error (a MNU for Character>>bitOr:) failed to job my memory as to the actual cause. Is there any chance the final line of McHttpRepository>>readStreamForFileNamed:do: could be changed from:
^ aBlock value: contents readStream to: ^ aBlock value: contents asByteArray readStream
-1 #asByteArray does an implicit text to bytes conversion (granted, a stupid one). This will (and had conflicted in the past) with the text conversion done automatically by the HTTP client. The response simply has to be binary because the data is binary.
I know that it would be best if Web Servers never served up binary content as text/plain - but it's not always in the power of someone who encounters this error to fix that. Failing that, the condition should probably be explicitly checked for and a more useful error message given, as the cause is far enough away from the symptom that it takes a bit of digging to find out what went wrong.
+1 Yes, the error should be reported better. As it is today is not acceptable. Normally, the ZnClient>>#accept: option (in combination with #systemPolicy) would do the trick. However, while a ZnMimeType text wildcard (text/*) is useful to require textual responses, no such general wildcard exists for (all) binary responses. We could try with (application/*) and hope that enough MC servers comply (I think most will use application/octet-stream or application/x-monticello anyway). I could try to make a 2.0 patch and see what happens.
Regards, Stuart
Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill