The .Str method gets confused by binary $.content in HTTP::Message

[zostay]

If I build an HTTP::Response object that places a Buf in $.content, the .Str method will fail with the following exception:

Cannot use a Buf as a string, but you called the Stringy method on it
  in method Str at <snip>/.rakudobrew/moar-nom/install/share/perl6/site/sources/36<snip>64 (HTTP::Message) line 231
  in method Str at <snip>/.rakudobrew/moar-nom/install/share/perl6/site/sources/99<snip>B5 (HTTP::Response) line 117
  ...

[jonathanstowe]

Hi, as it currently stands you can pass :bin to the .Str method and it will attempt to do something sensible. Obviously this doesn't help if the .Str is being called implicitly somehow.

I guess, as long as the content-type is set appropriately, it could try harder, bearing in mind that it both wants to send actually binary data as well as text data that may be in an encoding that Perl doesn't know about (and thus needs to be a Blob)

[zostay]

The :bin arg is irrelevant in this case. The same error occurs. Here's a code snippet demonstrating:

my $res = HTTP::Response.new(200);
$res.content = buf8.new; # $.content has to be primed for binary
$res.add-content("Hello World".encode);
say $res.Str(:bin); # fails with or without bin

The need for "priming" is a minor annoyance but might be considered a bug as well.

[zostay]

Actually, that example does not work. I had not realized that "".encode ~ "" was a legal operation. This code actually demonstrates the problem I'm seeing:

my $res = HTTP::Response.new(200);
$res.content = buf8.new; # $.content has to be primed for binary
$res.add-content: buf8.new(0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64);
say $res.Str(bin => ?(rand <= 0.5)); # fails with or without bin

The UserAgent itself avoids this problem. It would only come up with code that was putting bufs into the HTTP::Message without the help of UA, which had not yet been careful about encoding. Perhaps the onus is on the caller to be that careful instead.