Hi,

When I try to install HTML::Parser as well as Bundle::LWP I'm getting this following error

perl -MCPAN -e "install Bundle::LWP"

C:\Perl\bin\perl.exe C:\Perl\lib\ExtUtils\xsubpp -typemap C:\Perl\lib\ExtUtils\typemap -typemap typemap Parser.xs > Parser.xsc && C:\Perl\bin\perl.exe -MExtUtils::Command -e mv Parser.xsc Parser.c
cl -c -nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"3.56\" -DXS_VERSION=\"3.56\" "-IC:\Perl\lib\CORE" -DMARKED_SECTION Parser.c
'cl' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'

Please help me to install these modules

Thanks
Jey

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.

Queue: URI
Ticket http://rt.cpan.org/Ticket/Display.html?id=31273 >

URI-1.37 comes with this patch to address this issue:

http://gitorious.org/projects/perl-uri/repos/mainline/commits/d549f27f719dd489ea...

Queue: URI
Ticket http://rt.cpan.org/Ticket/Display.html?id=27 >

$u->query_form support for ";" was implemented in URI-1.37

Thu Jun 26 18:50:49 2008: Request 37148 was acted upon.
Transaction: Ticket created by jaekle@eventax.com
Queue: libwww-perl
Subject: Bug in LWP::RobotUA - Robot UA could access forbidden documents if clock is going wrong
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: jaekle@eventax.com
Status: new
Ticket http://rt.cpan.org/Ticket/Display.html?id=37148 >

Hello,

RobotUA compares as fresh_until time the local time and the remote
server time.

If the local clock is going wrong, the comparison won't work.

So RobotRules->allowed could return -1 and allow RobotsUA to access
forbidden documents!

Regards,

Matthias Jaekle

Hi,
Thanks for creating the great LWP and
Crypt::SSLeay<http://search.cpan.org/%%7Edland/Crypt-SSLeay-0.57/>
modules. I use it very often.

I am using LWP + https in a multithread perl script. I found that
sometime it crashs.

Is Crypt::SSLeay <http://search.cpan.org/%%7Edland/Crypt-SSLeay-0.57/>
thread safe ? If not, it is possible to make it thread safe ?

Does LWP + https use
Net::SSLeay<http://search.cpan.org/%%7Eflora/Net_SSLeay.pm/SSLeay.pm>at
all ? I am not sure about the relationship between
Crypt::SSLeay <http://search.cpan.org/%%7Edland/Crypt-SSLeay-0.57/> and
Net::SSLeay <http://search.cpan.org/%%7Eflora/Net_SSLeay.pm/SSLeay.pm> .
Currently LWP only use
Crypt::SSLeay<http://search.cpan.org/%%7Edland/Crypt-SSLeay-0.57/>,
right ?

Thanks a lot.. Great job !!

Harry

Queue: libwww-perl
Ticket http://rt.cpan.org/Ticket/Display.html?id=36132 >

Gracias ! :-)

On Tue, Jun 17, 2008 at 9:17 PM, Gisle_Aas via RT
rt.cpan.org> wrote: