in reply to Strange issue with mod_perl 2.0.10 / Apache 2.4 corrupting nfreeze data

Maybe (maybe) switching to ->decoded_content works, or maybe you need to add appropriate Content-Type headers (like x-application/binary) so that you receive the content as unmolested octets. C2 81 interpreted as UTF 8 would denote an unsupported/invalid Unicode character. Maybe something encodes some control character to that.

Replies are listed 'Best First'.
Re^2: Strange issue with mod_perl 2.0.10 / Apache 2.4 corrupting nfreeze data
by amasidlover (Sexton) on Mar 28, 2016 at 11:59 UTC

    I should have mentioned; I've tried both decoded_content and content and they both return the same.

    It would seem very strange for something to be embedding control characters mid response, but I haven't ruled it out.

    I'll see what other suggestions come up (as well as your Content-Type headers) and then roll forwards again as the roll forwards requires config changes etc. as well so takes some time.

[reply]
      I've tried adding Content-Type => 'x-application/binary' and it made no difference. I also wondered if a content-length header would help, but it made no difference either. I think I'll report a mod_perl bug and go from there.
[reply]

In Section Seekers of Perl Wisdom