Can't log in with w3m due to bad cookies

Bug #59510 reported by Björn Tillenius on 2006-09-08
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

The textbrowser w3m treats cookies from Launchpad as bad, as per RFC 2109, section 4.3.2, rule 3, and it seems that this makes it impossible to log in. By default the cookies are rejected, but even if you accept the cookies you can't log in.

Changed in launchpad:
assignee: nobody → stub

Björn Tillenius wrote:
> Public bug reported:
> The textbrowser w3m treats cookies from Launchpad as bad, as per RFC
> 2109, section 4.3.2, rule 3, and it seems that this makes it impossible
> to log in. By default the cookies are rejected, but even if you accept
> the cookies you can't log in.
> ** Affects: launchpad (upstream)
> Importance: Untriaged
> Assignee: Stuart Bishop
> Status: Unconfirmed

From a brief reading, if we fix this it means that logging onto will mean you are not logged into
Further, if you logged into and then,
you will have two distinct sets of session credentials and we would have to
handle this case when the user returns to

Stuart Bishop <email address hidden>
Canonical Ltd.

Diogo Matsubara (matsubara) wrote :

<twb> This cookie was rejected to prevent security violation. [RFC 2109 4.3.2 rule 3]
<twb> ...that's what plain w3m says re the cookie thing.

Changed in launchpad:
status: Unconfirmed → Confirmed
Martin Pitt (pitti) wrote :

Confirmed while playing around with a text-based apport frontend. lynx does not work either.

Michael Hofmann (mh21) wrote :

This bug prevents apport-cli from using w3m. Elinks seems to work though.

Stuart Bishop (stub) on 2007-07-27
Changed in launchpad:
assignee: stub → nobody
Christian Reis (kiko) wrote :
Download full text (4.7 KiB)

Well, I was reading 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:

The server, named, sends cookies of the form:

Set-Cookie: session_foo=foo; path=/;

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 does *not*

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

4.2.2 Set-Cookie Syntax

         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:

         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:

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 "" would match host names
     "" as well as "".

     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 "". 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 match the tail of the host
I would think not. But is tail matching even involved in de...


Christian Reis (kiko) wrote :

And, for the record, our cookies don't specify a Version. Here's my sanitized edge cookie:

Set-Cookie: edge=XXX;; expires=Thu, 30 Jul 2009 20:50:49 GMT; Path=/; secure;

So I believe we're not the ones making a mistake here, but w3m instead.

Scott Kitterman (kitterman) wrote :

OTOH, RFC 2119 was published in February 1997. While that appears technically correct, I think a decade is long enough. I think it reasonable for Launchpad to support an Internet BCP that existed for the better part of a decade before Launchpad even existed.

Selene ToyKeeper (toykeeper) wrote :

FWIW, I am able to log into edge via w3m, but not the production site. I'm actually posting this with w3m right now.

The version I'm using is 0.5.1-5.1+b1 from debian/testing x86_64, with default configuration.

Christian Reis (kiko) wrote :

Same here: I can log into and, but not into The headers are slightly different for each:
Set-Cookie: lp=XXX;; expires=Thu, 30 Jul 2009 22:54:10 GMT; Path=/; secure;
Set-Cookie: edge=XXX;; expires=Thu, 30 Jul 2009 22:54:47 GMT; Path=/; secure;
Set-Cookie: lp=XXX;; expires=Thu, 30 Jul 2009 22:56:12 GMT; Path=/; secure;

But from what I can see this is actually a bug in either w3m or the RFC (or both). I don't see any reason why it should be okay for to set cookies for, but not itself!

Christian Reis (kiko) wrote :

In reply to Scott K's comment: being practical, if the RFC doesn't allow people to be logged in across all our domains, then it's probably not a good idea to implement support for it. I think that's probably a bug in the RFC -- and perhaps one reason why it's not as widely adopted.

Selene ToyKeeper (toykeeper) wrote :

I've noticed something else potentially useful. It seems I can log into any launchpad domain except the base domain. In other words, these work:


But this domain fails:

I noticed the cookie is set for "" with a leading dot. This lets it work for all subdomains, but the base domain isn't a subdomain of itself. Maybe w3m doesn't think the "*." part is optional. If this is the case, some solutions are to set a second cookie without the leading dot, add "www." (or similar) to the base URL, or change how w3m matches cookies and domains.

Christian Reis (kiko) wrote :

Well, what I don't know is whether specifying a domain of just (with no leading dot) on cookies sent from would work and allow these cookies to be sent to subdomains of Because the spec seems unclear (see for some discussion of this) I'm also wary of changing this and breaking behaviour on other browsers. Does anyone concerned have the time to experiment and bring some research to the table?

Curtis Hovey (sinzui) on 2010-11-13
Changed in launchpad-foundations:
status: Confirmed → Triaged
importance: Undecided → Low
Curtis Hovey (sinzui) wrote :

I have confirmed that the current version of w3m allows me to login to any Launchpad and use any page.

Changed in launchpad:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints