← Back to team overview

launchpad-dev team mailing list archive

launchpad.net -> www.launchpad.net?

 

I diagnosed a bug last week: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/586908 .

I tried to give a concise but complete description of that problem in that bug.  To sum up, people can't authenticate using Lynx on launchpad.net (but *.launchpad.net, including edge.launchpad.net, is fine).  It appears to be because Lynx interprets Cookie domain-matching using a stricter reading of the pertinent RFC than most browsers do.

I think this is important, because I think it is important to have a supported terminal-based browser.  This is particularly important for people who want to use launchpadlib-based applications, such as apport, on server machines.  Lynx has been the only terminal-based browser that has worked for me (Links goes into a loop in the canonical-identity-provider application when I try it, for instance).

Moreover, what Lynx is doing is at least arguably correct.

As I said in comment #8, my proposal is that we should make non-beta requests to launchpad.net URLs render, not redirect; but have all local URLs from those pages (links, form submissions, OpenID redirect requests, ...) use www.launchpad.net. I think that would be the least disruptive solution.

It is still pretty disruptive.  I'd love to have a different answer.  Can someone suggest a better idea, or correct some aspect of my diagnosis?

Other approaches considered:

- Try to get Lynx upstream to change behavior.  This does not solve existing installations.

- Try to figure out why Links is breaking earlier in the authentication process (on canonical-identity-provider), and then hope that it does not have the same behavior as Lynx once it gets to the problematic Set-Cookie.  Then declare that we support Links, not Lynx.  Note that debugging Links is more difficult because it does not have (document?) a nice trace log like Lynx does, but Wireshark (+ some reverse proxies because of the HTTPS) might do the trick for debugging the Links problem.

Gary


Follow ups