Comment 5 for bug 59510

Revision history for this message
Christian Reis (kiko) wrote :

Well, I was reading http://www.sic.med.tohoku.ac.jp/~satodai/w3m-dev-en/200406.month/1022.html and noticed this section as relevant (sorry for the long paste, but there's no l:

Date: Thu, 11 Mar 2004 03:58:44 +0000
From: "Adam M. Costello" <email address hidden>
Subject: Re: [w3m-dev-en 00989] Cookie rejected

Gilles Casse wrote:

 > When a particular form is submitted, the following message appears:
 > "This cookie was rejected to prevent security violation [RFC 2109
4.3.2 rule 3]."
 >
 > The concerned url is:
 > https://gna.org//account/login.php

The server, named gna.org, sends cookies of the form:

Set-Cookie: session_foo=foo; path=/; domain=.gna.org

RFC-2109 4.3.2 rule 3 says that a cookie must be rejected if the request
host does not domain-match the domain attribute. The RFC includes a
very clear precise definition of domain-match, and gna.org does *not*
domain-match .gna.org.

However, that is irrelevant in this case, because RFC-2109 explicitly
disclaims jurisdiction over Set-Cookie fields that lack a Version
attribute:

4.2.2 Set-Cookie Syntax

     Version=version
         Required. The Version attribute, a decimal integer, identifies
         to which version of the state management specification the
         cookie conforms. For this specification, Version=1 applies.

4.3.1 Interpreting Set-Cookie

     The user agent applies these defaults for optional attributes that
     are missing:

     Version
         Defaults to "old cookie" behavior as originally specified by
         Netscape. See the HISTORICAL section.

Therefore, I think it is a mistake for w3m to cite RFC-2109 as a reason
to reject a Set-Cookie that lacks a Version attribute. If we want to
know how to properly handle such a Set-Cookie field, we need to consult
the Netscape cookie spec:

http://www.netscape.com/newsref/std/cookie_spec.html

Unfortunately, that spec is unclear:

     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".

     Only hosts within the specified domain can set a cookie for a domain
     and domains must have at least two (2) or three (3) periods in them
     to prevent domains of the form: ".com", ".edu", and "va.us". Any
     domain that fails within one of the seven special top level domains
     listed below only require two periods. Any other domain requires at
     least three. The seven special top level domains are: "COM", "EDU",
     "NET", "ORG", "GOV", "MIL", and "INT".

     The default value of domain is the host name of the server which
     generated the cookie response.

Does the domain attribute .gna.org match the tail of the host gna.org?
I would think not. But is tail matching even involved in deciding
whether to accept the cookie? The spec says that tail matching is
involved when deciding whether to send a cookie, but doesn't say that
tail matching is involved when deciding whether to accept a cookie.
The cookie is accepted if the host is "within" the domain. Is gna.org
"within" .gna.org? Again, I would think not, but this is even less
clear. Of course, even if you accept the cookie, that probably won't
help you if you then refrain from sending it back to gna.org because it
fails the tail-match.

Curiously, if the server were using RFC-2109 Set-Cookie (with
$Version=1), it wouldn't even include the domain attribute, and the
domain the would default to be the same as the host, and there would be
no problem. But for Netscape Set-Cookie (without $Version), the default
domain of gna.org would fail the two-dot requirement.

It looks to me like there is no way for a server with a second-level
name (like gna.org) to use Netscape cookies at all, at least according
to the Netscape spec. Maybe someone should ask Netscape for a
clarification of the discrepancy between their spec and their
implementation.

By the way, there is another reason to question w3m's citation of
RFC-2109. RFC-2109 was obsoleted a few years ago by RFC-2965, which
uses Set-Cookie2, and mentions using the old Set-Cookie field for
supporting Netscape cookies, but not RFC-2109 cookies. Could it be
that deployment of RFC-2109 cookies never got very far? RFC-2965 does
not even suggest legacy support for 2109; it seems to view Netscape
as the legacy, and 2109 as something to be forgotten (and barely even
acknowledged).