launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #03506
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