Re^2: use bytes vs packed data

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]
[download]

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]
[download]

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]
[download]

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.

Comment on Re^2: use bytes vs packed data Select or Download Code

Replies are listed 'Best First'.
Re^3: use bytes vs packed data by ikegami (Patriarch) on May 05, 2011 at 16:08 UTC
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?	[reply]
Re^4: use bytes vs packed data by RDOlson (Initiate) on May 05, 2011 at 21:55 UTC
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.	[reply] [d/l]