In a LWP application I'm just writing I have found a surprising
behaviour: Responses created by HTTP::Response::new and written to
disk with HTTP::Response::as_string can't be successfully parsed by
HTTP::Response::Parse.
The reason is simple:
HTTP::Response::new creates a response from its headers, then sets the
code and message as given by the $rc and $msg parameters. It does
*not* define a protocol.
my $self = $class->SUPER::new($header, $content);
$self->code($rc);
$self->message($msg);
However, HTTP::Response::parse expects the first nonblank item to be
the protocol, which hasn't been defined by HTTP::Response::new.
my($protocol, $code, $message) = split(' ', $status_line, 3);
Hence the original code is stored in $response->protocol and the
original message in $response->code - the latter makes methods like
$response->is_success() croak.
I don't see a really *good* solution. In my opinion
HTTP::Response::new ought to allow to add a protocol. But changing
the parameters might break existing code.
As a fallback, HTTP::Response::parse could set the protocol to undef
if it turns out to be a three-digit number, assigning this value to
the code (after assigning to the message what was parsed as the code).
Maybe the best fallback would be to write some "undefined" value in
HTTP::Response::as_string if the protocol is undefined:
my $status_line = "$code";
my $proto = $self->protocol;
- $status_line = "$proto $status_line" if $proto;
+ $status_line = $proto ? "$proto $status_line"
+ : "UNKNOWN $status_line";
But again, this might break existing code.
Currently I'm working around the problem by setting the protocol
in my own code before stringifying like this:
$response->protocol('UNKNOWN') unless $response->protocol();
I don't like that too much either.
I could submit patches for all the fallbacks and workarounds -
what would be The Right Thing To Do?
--
Cheers,
haj
