[Pharo-project] McHttpRepository and text/plain
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 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. Regards, Stuart
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
Hi Sven,
-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.
Yes, I understand. The important thing is that at the moment is that a misconfigured server results in something that gives the appearance of a Pharo bug.
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.
Excellent! Regards, Stuart
participants (2)
-
Stuart Herring -
Sven Van Caekenberghe