more LWP bit rot

Anyone know what this shit is and how to stop it?

Use of uninitialized value $vals in index at /usr/local/share/perl5/HTTP/ line 277.
Use of uninitialized value $vals in concatenation (.) or string at /usr/local/share/perl5/HTTP/ line 280.

I don't know when or why it started, but I've tried all of:

upgrade HTTP::Headers
upgrade LWP
upgrade HTML::HeadParser
upgrade LWP::UserAgent
upgrade HTTP
upgrade HTTP::Request

/usr/local/share/perl5/HTTP/ $VERSION = "6.10";

This is on a CentOS machine, not a Mac, in case that matters.

Previously, previously.

Tags: , , ,

10 Responses:

  1. Reini Urban says:

    I don't know why, and I cannot repro it nor had the same bitrot, but I can explain when:

    This HTTP/ warning with 6.10 will appear with an empty header value.
    Headers are processed here: $self->_sorted_field_names, the empty value you get is read at my $vals = $self->{$key};

    I debugged it like:
    perl -S -d lwp-request -E -m HEAD
    > b postpone HTTP::Headers::as_string
    > c
    and then when you hit it get a better breakpoint
    > b 264 !$vals
    > c
    and then you see which header is empty, with
    > x $key

    • moof says:

      And you can probably bodge around the warnings in the meantime by changing line 263 of from
      my $vals = $self->{$key};
      my $vals = $self->{$key} // '';
      to force a defined-but-empty value to exist. (Assuming you're using perl 5.10 or higher.)

  2. Ben says:

    I suspect this started with 6.08, or more specifically this commit.

  3. Zak Elep says:

    By not using LWP in the first place?

    Its 2015, there are more options now, like Furl::HTTP and Mojo::UserAgent.

    • Aaron says:

      Yes, let us discard old and predictable brokenness for functionally identical, yet new and exciting, brokenness! Thank God you're here.

  4. ether (Karen Etheridge) says:

    POSTing upload for HTTP-Message-6.11.tar.gz to
    PAUSE add message sent ok [200]

    (RT tickets will get noticed faster though) :)

  5. After some years of not a lot happening because there was only one maintainer/releaser I got annoyed and did some cat herding; there's now an org on github, and RT tickets will hopefully get responded to.

    I went and poked 'em for you and hopefully the HTTP::Message release solves the proximate problem, but if you see anything else that looks like bitrot please do throw an RT ticket in or something (or just bitch on here, tbh, I read back through the archives every month or two :)

  6. Joker_vD says:

    I believe it's because you set the value of a header to something that's not actually a string or a bytearray or whatever thing is actually expected to be there — I had the same problem when `use encoding "utf-8"` was present.

    Probably messing with 'hname' => $hvalue VS 'hname' => "$hvalue" VS 'hname' => Encode::decode('cp437', $hvalue) in places where headers are set would fix it. Maybe not.

  7. Mjog says:

    <nelson> Har har!