Re^2: How to reconstruct HTTP::Response from file properly

A unicode problem is actually my thought as well... But I think I have everything setup correctly:

$stored_as_file = Compress::Zlib::memGzip($stored_as_file);

open(FILE ,">:utf8", "$file") or die "err: $!";
binmode FILE;
print FILE $stored_as_file;
close(FILE);
[download]

is what I use to write the data compressed to disk. And this

local( $/, *FILE );
open(FILE, "<:utf8", "$file") or die "err: $!";
binmode FILE;
my $stored_as_file = <FILE>;
close(FILE);
$stored_as_file = Compress::Zlib::memGunzip($stored_as_file);
[download]

is used to read it back. BTW: I am running Linux (no binmode there, I thought...).

Comment on Re^2: How to reconstruct HTTP::Response from file properly Select or Download Code

Replies are listed 'Best First'.
Re^3: How to reconstruct HTTP::Response from file properly by Corion (Patriarch) on May 02, 2007 at 10:34 UTC
Your compressed data is not unicode anymore - it's compressed octets. So I'd write it out and read it back in as plain as possible without the `:utf8`. The "No binmode for unixish OSes" mantra is a cargo cult meme going back to the days where there were no IO layers. You should always use `binmode` on your binary files.	[reply] [d/l] [select]
Re^4: How to reconstruct HTTP::Response from file properly by isync (Hermit) on May 02, 2007 at 11:18 UTC
OK, I removed the utf8 thing on the writes/reads (they were just a result of guessing to find the bug, anyway...) But actually the problem is getting esoteric now - sometimes it works sometimes it don't! I wrote a test script to get always the same page, write it to disk, read it back and compare both. The data is the same length before and after store/read (I don't know how to compare them bitwise). Then I thought it has to do with me writing to disk and reading back too fast. First I tried a sleep() in between. Then I threw in File::Sync in the write routine to be sure: `use File::Sync qw(fsync sync); open(FILE ,">$file") or die "err: $!"; binmode FILE; print FILE $stored_as_file; fsync(\*FILE) or die "fsync: $!"; close(FILE); sync();` [download] still, the script randomly gets it right, then don't. Another guess is that it has to do with Compress::Zlib. I am using it in the read/write and HTTP::Response uses it in the decoded_content() method to decode the gzipped http content. Is it possible that gzip does not flush between uses of the memGzip/memGunzip sub? My last guess is an observation. The partly gzipped content that ends up in the header is always cut at a certain series of characters. Maybe the gzipped content does change from get() to get() and my script breaks when a certain char is in it!? (Would explain the irregular behaviour. Maybe HTTP:Response::parse() wrongly splits the binary compressed octets of the gzipped part of the http message and so a part of it ends up in the header. Possible?	[reply] [d/l]