HTTP::Message constructor can be manipulated

[Mohammad Sajid Anwar]

Hi @oalders

Just noticed the method new() in the module HTTP::Message as below:

sub new
{
     my($class, $header, $content) = @_;
     if (defined $header) {
         Carp::croak("Bad header argument") unless ref $header;
         if (ref($header) eq "ARRAY") {
             $header = HTTP::Headers->new(@$header);
         }
         else {
             $header = $header->clone;
         }
    }
    else {
        $header = HTTP::Headers->new;
    }
    if (defined $content) {
      _utf8_downgrade($content);
    }
    else {
        $content = '';
    }

    bless {
       '_headers' => $header,
       '_content' => $content,
    }, $class;
}

The constructor assumes, $header parameter would be either undef, ref, array ref or HTTP::Headers object.
What if $header is hashref or scalarref or some random object?
In my humble opinion this can easily be taken care of.
If you don't mind then I am happy to submit PR for you to review.

Many Thanks.

Best Regards,
Mohammad S Anwar

[Olaf Alders]

Hi @manwar,

If I'm understanding correctly, you'd like the constructor to throw an appropriate exception if $header is not an ArrayRef or an Object?

Best,

Olaf

[Mohammad Sajid Anwar]

Hi @oalders

You got my point :-)
My intention was to make constructor validate $header and not assume anything.

Best Regards,
Mohammad S Anwar

[Theo van Hoesel]

the thing is, you are going to change historical behaviour ... as it just accepted anything, one needs to be very careful tho react 'something'.

But yeah, in any newly, modern code, validate and have different contractors for each acceptable type. I'd strongly disagree with such 'accept all' constructor... but hey... someone thought it was a good idea!

I'm not confident about such change, and would need enough insurance that such validation would not suddenly reject stuff in the wild.

[Mohammad Sajid Anwar]

I take your point @vanHoesel and hence I didn't work on the proposed solution.
Instead I raised issue and wanted to discuss with the author and like minded.
The proposed change would help user understand the cause of issue clearly.

[Olaf Alders]

I can see both sides here. My preference would be not to fix this right now, since I don't think there's a pressing need for it and as @vanHoesel pointed out, it could have some side effect on other code which we may not be able to predict.

Thanks for raising this @manwar. I think it was a conversation worth having.