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:

-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.

Excellent!

Regards,
Stuart