post_ok doesn't recognize any LWP_options
Closed this issue · 9 comments
The hashref of LWP_options for post_ok is passed to $mech->post as a reference instead of as a list. This means that it is useless for setting any request options (Content-Type is the one I care about here), and can only set form parameters.
Compare (from post_ok):
$self->post( $url, \%opts );
vs. (from get_ok)
$self->get( $url, %opts );
Fix post_ok method and pass %opts to the method instead of \%opts.
I think I have a patch that allows access to the full range of post()'s capabilities without breaking backward compatibility for existing users of post_ok().
I'd love to see it.
Trying to figure out how to reference the issue in a pull request. Hopefully won't take too long.
Can this be merged? It's two and a half years later and I just had to override post_ok in order to resolve this bug.
I contend that this is a bug because the docs say I can pass options just like the parent class, except as a hashref, and when I do that, it doesn't unpack the hashref back into the hash.
Of course, this is kinda hard to do because the parent class takes a list, and interprets it differently - not all invocations of HTTP::Request::Common::POST are hash-shaped:
POST $url, $form_ref, Header => Value,...
This invocation differs because the hash-shaped list starts at argument [2] not argument [1]
I've created a documentation only change pull request in an attempt to address this. Hopefully that's something that works for everyone as a middle ground.
I'm happy to discuss if anyone is interested.
I just hit this problem as well, trying to simulate an LWP::UserAgent->post($url, Content=>'...', 'Content_Type'=>'application/json') call.
Traced the problem to post_ok() passing options as a hash-ref to LWP::UserAgent->post (via WWW::Mechanize) instead of a hash.
This has bit a ton of people. You have a PR, and you have an issue but yet you don't want to fix..
Its not like this is a huge lib id say fork it but they have "claimed" the namespace" ohhh lovely perl cpan woes.
Ran into this as well, bumping.
+1 -- just wasted a while trying to figure out why the content-type wasn't getting set correctly in my unit tests :(