This is by far the sanest HTTP client implementation I happened to come by. Makes simple things easy, yet leaves you in control.
It's surprising how many clients don't even understand response code classes (is_success, is_redirect, is_error, ...) don't grok Encoding headers or implement subrequests after redirects or authentication sanely. This one does very well.
Since a couple of versions ago it implements, in addition to common synchronous interface, callback-oriented API that's handy for handling streaming responses.
Existence of this module alone is a good case for using Perl to implement a Web client.
I really like this set of modules, because they save me so much time. The functions do what I think they're going to do, and the documentation always heads me in the right direction. Unlike the horrific CGI.pm, even when I was a complete beginner at Perl I was able to use these modules without severe stress, which is one of the big reasons I like them.
I'm sure these modules have their limitations but if I need to stretch the boundaries of what these can do, I'd expect to have to fiddle with source code and write my own modules. I'd much rather have a simple thing to make straightforward jobs easier than a complicated thing which I can't use to "just get it done".
libwww-perl is one of those venerable CPAN distributions that has been around for years and for which there is simply no alternative. It makes writing www-clients very easy and offers a decent interface. Furthermore, switching to SSL-encrypted HTTPS will require very little or not changes at all to your code-base.
It has however quite a few flaws and makes in parts arbitrary assumptions that are difficult to get by.
We use it extensively at work where we are using HTTP as a sort-of RPC. We do stretch things a little but we are certainly still within the specifications of HTTP. We were therefore surprised and rather disappointed to see how many bugs this (supposedly) mature module has: It limits the amount of header-fields to 128. The interface does not allow to increase this value so we had to redefine bits of HTTP::Methods in a very ugly way. The part that reads the HTTP response-header from the network is buggy. LWP is doing the right thing for the body interestingly enough. Again, we had to redefine one of libwww's method to work around this. Finally, HTTP::Message::parse() is broken in that it does not understand header-fields with multiple values. This is bizarre because a request with multi-valued headers (via push_header()) is correctly stringified into an HTTP request.
By and large, our impression is that libwww-perl works well for most of the common cases. Stretch it a little, though, and you'll soon find it to be a less agreeable companion.