wish: HTTP::Cookies should have easy access methods [rt.cpan.org #12151]

[oalders]

Migrated from rt.cpan.org#12151 (status was 'open')

Requestors:

• mark@summersault.com

From on 2005-04-05 16:56:29:

I'm using Mech for testing, and I would like an easy way to express: "Did I get back a cookie named "foo"?".

Right now it appears to do this would involve calling scan() with a callback. 

I would like a high level method for cookie access to be added, similar in spirit to Mechs find_link().

So maybe for my case it would work like this:

$something = $cookie_jar->find_cookie( name => 'foo' );

And maybe "$something" should be an object for a single cookie, with several accessor methods.

This is beginning to sound like real work now. :) 

From on 2005-04-06 14:47:38:

[guest - Tue Apr  5 12:56:29 2005]:
> I'm using Mech for testing, and I would like an easy way to express:
> "Did I get back a cookie named "foo"?".

You shouldn't need to have to test for specific cookies when testing an
app. Just test the app works. It shouldn't matter if the cookie changes
names for the application to work correctly.

I don't think there's real need for that API.

From on 2005-04-07 16:02:51:

hmm.. a previous comment I left seems to be missing. Anyway, here's
anothe r real life use case:

The login form has a "remember me" button, which sets a cookie for 1
year instead of 1 hour if it's checked. 

It's not reasonable for a test to wait a year (or an hour!) to see if
the cookie set appropriately.

A reasonable test is to examine the contents of the cookie. 

  Mark

From stillwell@cpan.org on 2005-08-10 13:32:45:

[guest - Wed Apr  6 10:47:38 2005]:

> You shouldn't need to have to test for specific cookies when testing
>    an
> app. Just test the app works. It shouldn't matter if the cookie
>    changes
> names for the application to work correctly.
> 
> I don't think there's real need for that API.

I have a need to this functionality too; in my case the cookie is read
by a Flash app--so I can't test, from Perl, whether the app works.

(In any case, I think there's a case for such a method by appeal to
symmetry--there's a set, why not a get?)

From stillwell@cpan.org on 2005-08-10 15:33:01:

Quick hack to add a get_cookie_hash method (doesn't filter by host, etc.):

package HTTP::Cookies;

sub get_cookie_hash {
    my ($self) = @_;

    my $hash = { };

    $self->scan(sub { $hash->{$_[1]} = $_[2]; });

    return $hash;
}

From gaas@cpan.org on 2009-07-26 18:54:47:

Without a concrete API suggestion I'm not going to do anything about this.

From markstos@cpan.org on 2009-07-27 13:11:10:

On Sun Jul 26 14:54:47 2009, GAAS wrote:
> Without a concrete API suggestion I'm not going to do anything about this.

Thanks for the reply, Gisle. 

Then we can put it in my court to make some concrete API suggestions.

From markstos@cpan.org on 2009-07-28 02:51:05:

Here's a more specific API suggestion:

# Returns the first cookie that relate to the current page and have the
name of 'foo':

my $cookie = $cookie_jar->find_current_cookie( name => 'foo' );

The "find" method is intentionally modeled after the "find*" methods in
WWW::Mechanize. The initially implementation may only support the "name"
search or other easy targets. Other criteria could be added later.

The notion of "current cookies" is already in "add_cookie_header()", but
needs to be factored-out for re-use.

The "$cookie" returned would be an object that would have an API
identical to CGI::Cookie, for familiarity and perhaps direct code
re-use.  If you are not a fan of CGI::Cookie, modeling
CGI::Simple::Cookie or Mojo::Cookie are also possibilities. 

If heading in this direction seems interesting, myself or someone else
could start to look at a patch. 

   Mark

From ether@cpan.org on 2017-01-25 21:39:01:

migrated queues: libwww-perl -> HTTP-Cookies