Re: Accomodating Netscape-style cookies?
Kartik Subbarao (subbarao@computer.org)
Fri, 06 Mar 1998 19:34:21 -0500
This is a multi-part message in MIME format.
--------------505C7E355982F308FE6EB9F3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Gisle Aas wrote:
> Kartik Subbarao <subbarao@computer.org> writes:
>
> > I'm trying to use HTTP::Cookies to talk to a web application that
> > follows the "looser" Netscape-style Cookie definition
> >
> > http://www.netscape.com/newsref/std/cookie_spec.html
> >
> > as opposed to the more "strict" definition specified in RFC 2109.
> >
> > Specifically, this application generates cookies with the pattern of
> > domain=foo.bar.com from the host foo.bar.com. It also generates
> > cookies with domain=.bar.com from baz.foo.bar.com. Both of these are
> > verboten according to RFC 2109, but Netscape works fine with them.
>
> Is domain=foo.bar.com supposed to mean that cookies should only be
> returned to host foo.bar.com or that both foo.bar.com and for instance
> xxx.foo.bar.com should get it? What does Netscape do (probably it
> just tries to match the domain name at the end of the hostname as it
> is ans will send cookies to both xxx.foo.bar.com and foo.bar.com)?
Yeah, it does tail matching. Here's the excerpt from the spec:
---
When searching the cookie list for valid cookies, a comparison of the
domain attributes of the cookie is made with the Internet domain name of
the host from which the URL will be fetched. If there is a tail match, then
the cookie will go through path matching to see if it should be sent. "Tail
matching" means that domain attribute is matched against the tail of the
fully qualified domain name of the host. A domain attribute of "acme.com"
would match host names "anvil.acme.com" as well as
"shipping.crate.acme.com".
---
> > One thing I was thinking of doing was adding some pacifying logic
> > to extract_cookies, wrapped around if ($netscape_cookie). For example,
> > not automatically prepending '.' to the domain name, and allowing
> > baz.foo.bar.com to set a cookie for .bar.com.
>
> This sounds acceptable to me.
>
> > I suspect that Gisle and others have probably wrestled with this issue
> > before. Any suggestions? Do people think a patch that accomodated
> > Netscape-style cookie specification would make sense?
>
> I think so.
Okay. Attached to this message is a patch to Cookies.pm that does the above
things.
-Kartik
--------------505C7E355982F308FE6EB9F3
Content-Type: text/plain; charset=us-ascii; name="patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="patch.txt"
*** Cookies.pm.orig Sat Sep 20 08:17:03 1997
--- Cookies.pm Fri Mar 6 18:33:32 1998
***************
*** 286,292 ****
LWP::Debug::debug("Domain $domain contains no dot");
next SET_COOKIE;
}
! $domain = ".$domain" unless $domain =~ /^\./;
if ($domain =~ /\.\d+$/) {
LWP::Debug::debug("IP-address $domain illeagal as domain");
next SET_COOKIE;
--- 286,293 ----
LWP::Debug::debug("Domain $domain contains no dot");
next SET_COOKIE;
}
! # RFC 2109 requires a '.' before the domain name. Netscape doesn't.
! $domain = ".$domain" unless $domain =~ /^\./ || $netscape_cookies;
if ($domain =~ /\.\d+$/) {
LWP::Debug::debug("IP-address $domain illeagal as domain");
next SET_COOKIE;
***************
*** 297,303 ****
next SET_COOKIE;
}
my $hostpre = substr($req_host, 0, length($req_host) - $len);
! if ($hostpre =~ /\./) {
LWP::Debug::debug("Host prefix contain a dot: $hostpre => $domain");
next SET_COOKIE;
}
--- 298,306 ----
next SET_COOKIE;
}
my $hostpre = substr($req_host, 0, length($req_host) - $len);
! # RFC 2109 doesn't allow y.x.foo.com to set a cookie
! # for domain=.foo.com. Netscape does.
! if ($hostpre =~ /\./ && !$netscape_cookies) {
LWP::Debug::debug("Host prefix contain a dot: $hostpre => $domain");
next SET_COOKIE;
}
--------------505C7E355982F308FE6EB9F3--