in reply to How to reconstruct HTTP::Response from file properly

You don't show us how you save and restore the data to and from disk. Does the following code work for you?

use strict;
use Test::More tests => 1;

# setup, to be provided by you

my $response = $useragent->get($url);
my $stored_as_file = $response->as_string;
my $restored_response = HTTP::Response->parse( $stored_as_file );

is $stored_as_file, $restored_response->as_string, "->as_string() is i
+dempotent";

[download]

If that code works for you and prints "OK", then the problem is with your saving and restoring, most likely because you're running on a system with a Unicode locale, or Win32. Most likely, you're missing a 

binmode $fh;

[download]
after your 
open my $fh, ">", $temp_response_name or die "Couldn't create '$temp_r
+esponse_name': $!";

[download]
.

Replies are listed 'Best First'.
Re^2: How to reconstruct HTTP::Response from file properly
by isync (Hermit) on May 02, 2007 at 09:37 UTC
    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...).
[reply]
[d/l]
[select]

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

In Section Seekers of Perl Wisdom