On Sat, Jul 5, 2008 at 6:39 PM, Bill Moseley <[EMAIL PROTECTED]> wrote:
> HTTP::Message has a decoded_content() method that will attempt
> to uncompress based on the Content-Encoding header in the response.
>
> It's wrapped in an eval which will trap exceptions when trying to
> require the modules used to uncompress the content.
>
> It would make sense that I would set Accept-Encoding based on if I
> have those modules installed.
RIght.
> Since the list of modules (Compress::Zlib and Compress::Bzip2) is
> internal to HTTP::Message, would it make sense to provide a method
> that could set the Accept-Encoding based on what HTTP::Message uses?
> Something like:
>
> $req->set_default_accept_encoding;
I don't like defaults to be set at that level given that we already
have a $ua->default_header() method, so I think it should be something
like:
$ua->default_header("Accept-Encoding", join(",",
HTTP::Message::decodable()));
> I'm not clear if there's a need to also specify a quality for the
> encodings in the Accept-Encoding header.
I don't think we need to worry about this initially.
> This can't be the default as it would break existing users.
>
> I often notice code that uses $res->content instead of
> $res->decoded_content. Most of the time it seems like users really
> want the decoded content.
>
> I kind of wonder why $res->content is not decoded by default (and
> provide $res->raw_content for those that need it).
It's mostly because of history and compatibility with the original
content() method. Both are useful in different contexts. I don't
find the current situation bad. Since decoded_content() can be
expensive and can fail I think the longer name makes it obvious what's
going on how you should use it.
--Gisle
