in reply to use bytes vs packed data

On a hunch, check if the following helps:

utf8::downgrade( $string_to_pass_to_rabbit );

If so, that would indicate a bug in Rabbit. If not, let me know and I'll look into it.

Update: It could also indicate a bad input. I would also appreciate the output of

use Devel::Peek; Dump( $string_to_pass_to_rabbit );

Replies are listed 'Best First'.
Re^2: use bytes vs packed data
by RDOlson (Initiate) on May 04, 2011 at 19:56 UTC

    With use bytes turned off:

    SV = PV(0x1c71c9e8) at 0x1c202710 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) PV = 0x1cab9940 "\0\0\3\302\261---\nCONTENT_LENGTH: [etc]

    With use bytes turned on:

    SV = PV(0xbfdd1e8) at 0xb734730 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0xbfeb710 "\0\0\3\261---\nCONTENT_LENGTH: [etc]

    With use bytes turned off and with calling utf8::downgrade on the string before dumping:

    SV = PV(0xd5ed9e8) at 0xd0d3710 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0xd98b100 "\0\0\3\261---\nCONTENT_LENGTH: [etc]

    Calls to Encode::is_utf8 are also tracking those values as noted by the dump.

    aHA.

    Resorted to reading the code in pp_pack.c, discovered that the UTFness of a packed string appears to be based on the UTFness of its components (which makes sense). The second string I'm packing here came from the Net::Async::FastCGI::Request stdin data, and was UTF8-flagged. So the question turns into how to convince that module to forget about encodings in its I/O - the code I'm building here is just relaying bits from one place to another and shouldn't be touching them.

      The second string I'm packing here came from the Net::Async::FastCGI::Request stdin data, and was UTF8-flagged.

      From what you say, it sounds like rabbit wants bytes. Did you encode the data? Why are you decoding an HTTP request in the first place?

        I'm not explicitly decoding anything in my code -- I just call Net::Async::FastCGI::Request->read_stdin. However, reading through that I see that THAT code is explicitly calling a UTF8 decode (it has a default encoding set to UTF8).

        So it looks like the correct solution is to explicitly set the default encoding to undef on the FastCGI object. Thanks all for the clues to get here ... this was not at all obvious to me.