On Sep 4, 2008, at 07:06, Russ Schnapp wrote:
I'm not sure whether you're still interested in this, but I think
I've come across a bug in HTTP::Cookies. If you're not the right
person for me to handle this, please let me know who is.
I'm the right one; but it's usually best to send requests like this
to the libwww mailing list. Cc:-ed.
The problem is in add_cookie_header. If the cookie version is
nonzero and the cookie contents include a non-alpha (\W) character,
it escapes any quotes or slashes in the cookie value.
Why do you specify an nonzero version number without using the Set-
Cookie2 header?
I'm thinking that the right fix for this might be to just force
'version=0' for any cookie set with 'Set-Cookie'. This patch achieve
that:
--- a/lib/HTTP/Cookies.pm
+++ b/lib/HTTP/Cookies.pm
@@ -237,6 +237,9 @@ sub extract_cookies
$expires++;
}
}
+ elsif (!$first_param && lc($k) =~ /^(?:version|
discard|ns-cookie)/) {
+ # ignore
+ }
else {
push(@cur, $k => $v);
}
The problem arises when the server has delivered a cookie value
that is ENCLOSED in quotes, i.e.,
Set-Cookie: member="whatever"; version=1; Path=/
When it comes time for add_cookie_header to do its thing, it generates
Cookie: member="\"whatever\""; $Path="/"
Cookie2: $Version="1"
I guess there are 2 bugs here:
1) The biggest problem is with the quoting. I think I've fixed
this by inserting one line in Cookies.pm:
# do we need to quote the value
if ($val =~ /\W/ && $version) {
$val =~ s/^"(.*)"$/$1/; ### RLS 9/3/08
$val =~ s/([\\\"])/\\$1/g;
$val = qq("$val");
}
2) The second problem is with the treatment of the Path and version
fields. They appear to be treated as if they were cookie values.
And yet they are transmitted with a prefix of "$". I REALLY don't
understand what's going on here, and I'm not inclined to mess with it.
Read RFC 2965 if you want to understand the deal with $Path and
$Version.
--Gisle
