httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: Apache::Cookies vs CGI::Cookies
Date Fri, 22 Apr 2005 20:41:31 GMT
Bram <perl@wizbit.be> writes:

[...]

>> Actually I take that back.  In apreq2, string context calls value(),
>> which is what I'd rather backport to apreq1 (instead of using as_string).
>
> Are you sure of that? I downloaded libapreq2-2.04_03-dev.tar.gz in it there
> is a file called Cookie_pm (in glue/perl/xsbuilder/Apache/Cookie) which has
> the following code:
>
> package Apache::Cookie;
> use overload '""' => sub { shift->as_string };

That's true for 2.04-dev, but it's not true for 2.05-dev.  I suppose
that's another delta that I need to document somewhere.

> But anyway, I wasn't really talking about backporting, I was talking about
> making the documentation of Apache::Cookie (of libapreq1) true... it has this
> line: 'Except for the request object passed to Apache::Cookie::new, the OO
> interface is identical to CGI::Cookie.' which is not true unless as_string is
> called in string context. 

The difference boils down to this: is our Cookie API request-oriented
or response-oriented?  Overloading with as_string() just makes it easy
to send outgoing cookies, when really this project is about parsing incoming
ones.

I'm seriously considering removing bake() and bake2() from the C API, 
because that way I could also remove headers_out from the apreq_module API.
We'd still keep them as perl subs for Apache2::Cookie, but they just 
wouldn't be portable to APR::Request::CGI anymore.  Any opinions?

-- 
Joe Schaefer

Mime
View raw message