If you want to get details like the Server header-value (assuming the server you got the reply from set it) you're going to need the full-featured OO LWP class, perhaps by inspecting an object within the HTTP::Headers class that can return arbitrary headers from a successful request.

The LWP::Simple class is a functional-Perl (sometimes called just FP) library that hides the "complex" class details. The return value of LWP::Simple::head() is documented to return a TRUE value on success (and while it is not formally documented, it seems to return undef on failure, which evaluates to false in a boolean context.)

Update: as GrandFather pointed out, you can certainly name your variables, or even stuff them into a hash. I think OP was asking about accessing the "hashref" (which the API says is a boolean) returned in scalar context. For an intro to scalar vs array context, this tutorial may be of use. /Update.

What you're seeing when you call Data::Dumper::Dumper() on the return value is actually a Perl object (see the perlobj docs) which just happens to evaluate to TRUE in boolean context. According to the API, you're not supposed to consider whatever else comes back (although traditionally a true boolean reply is simply the value 1, but clearly isn't always going to be as evident here.)

I would strongly advise you to avoid relying on the content you get in the hashref returned by the FP class methods unless they explicitly document returning an object of a particular class. In this case, it appears the returned object is of the class HTTP::Response, but per the API, there's no reason to believe this will be forward-compatible or will remain a stable access method.

Hopefully this clears up the confusion on the volumes of data you see; you're effectively looking at the object's internal structure, and it's generally unwise to rely on (or certainly edit!) an object's structure; exceptions to this can include if you're creating a subclass, or simply willing to accept that you're relying on a "private" part of the class. Perl won't stop you from playing with what C++ or Java programmers might call "private" class/method variables, but it's simply best not to.