I am assisting someone at long distance who is attempting to do a cpan
install Bundle::LWP.

Her make fails on just one test line, quote

live/https................FAILED tests 1-2

Failed 2/2 tests, 0.00%% okay

Is there serious or trivial? Can I advise her to go ahead and force the
install, or what should she look at to get the test to run?

Thanks for your advice,

Dave Cortesi

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.

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'm not clear if there's a need to also specify a quality for the
encodings in the Accept-Encoding header.

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).

Hello all,

I have mechanized a site using LWP and Mechanize that has been working
for about a year, but now no longer does. The site owner has made some
recent changes, but I think mechanize, or more precisely HTML::form
might be having trouble parsing the page and I'd like to find out why.

In order to make the form work, I set the __EVENTTARGET hidden field to
a certain value, but as of this week, the script dies with:

$self->mech->field('__EVENTTARGET',
'ChangeViewControl1$ImpersonateCommand');
No such field '__EVENTTARGET' at
/usr/lib/perl5/site_perl/5.8.7/WWW/Mechanize.pm line 1247

Sure enough, a form dump no longer shows the __EVENTTARGET field,
however, the 'view source' from firefox shows that there are several
hidden fields created. Notably, the first three that are blank,
__EVENTTARGET, __EVENTARGUMENT, and __LASTFOCUS are all missing from the
form dump. __VIEWSTATE and __EVENTVALIDATION are both fine.

Here is a sample of the page source causing the trouble:

Hi *,
At first thank you for great library!

I would like to report one problem with DYNAMIC_FILE_UPLOAD and propose
solution.
We use LWP for uploading files to HTTP server. The problem is that we
don't know how many files users could have.
Teoretically "many". ;-)

Becase we don't know even how big the files are, so we use
DYNAMIC_FILE_UPLOAD.
It perfectly works when there are just few files. Doesn't matter how big
they are, of course, DYNAMIC_FILE_UPLOAD works.

The problem arises when users have e.g. 400 small files.
At Solaris it leads to "Too many open handles" error message.
At Win XP it ends with crash.

I played around a little bit and prepare solution for us. Which seems to
be working nice here.
I'm quite new to Perl so maybe it is not the perfect solution, but I
would like to give an idea how I've solved this.