Comment 7 for bug 586908

The bug 535456 has been bothering me, so I hoped that investigating this one might help.

I compared lynx trace logs for going to launchpad.net (broken) and edge.launchpad.net (working).

Working backwards, the final request (the one that is supposed to be authenticated but sometimes is not) contains a session cookie in the edge (working) version and not in the non-edge (broken) version. That is what I'd expect, given the behavior. So why don't we have a cookie?

The problem is that Set-Cookie header that the page sends on both edge.launchpad.net and launchpad.net uses the domain of .launchpad.net. Lynx is apparently interpreting this strictly, according to RFC 2109: a "wild-card" domain with a preceding dot does not apply to a domain without a dot. Standard graphical browsers are looser in this regard. This comment appears to describe the same problem in another context: http://drupal.org/node/313606#comment-1259826 .

I verified that this was the problem by doing a temporary hack on a local branch of Launchpad that eliminated the preceding dot in the domain cookie. This "fixed" the problem.

AFAICT, Lynx is supposed to warn when it ignores cookies. It is also supposed to honor the COOKIE_LOOSE_INVALID_DOMAINS configuration value, which seems to be supposed to control this behavior. I couldn't get it to work. Maybe I misunderstand.

Simply moving launchpad.net to www.launchpad.net (or some other XXX.launchpad.net) would solve it, of course. That would be a risky change--for instance, it would break scripts that posted to hard-coded URLs at https://launchpad.net. Unfortunately, I don't have any more appealing ideas at the moment.