On Mon, Feb 20, 2012 at 06:38:54AM +0100, Nicolas Mailhot wrote: > > As a non-browser client, what should git do? We can't make sense of the > > content at http://login.corporatenetwork, which is most likely an HTML > > form asking for credentials (or even money, if the captive portal is > > something like a public wireless provider). The best we can probably do > > is die and say "apparently you need to go http://login.corporatenetwork > > in a browser before making your request". > > Actually, the best would be to launch something capable of interpreting html > forms on the url given by the error. Doing that portably is near impossible (keep in mind that git runs on things like antique versions of Solaris). Not to mention that git is often running without a user present, or on a remote system connected to the user only by ssh. So our best bet would probably be a configuration option to tell git how to run a browser. Distributions which ship binary packages could ship a sane default for their system. > But short of that, that depends on how good git is at resuming work > later. Error 511 can occur at any time, not just on initial connection > (because credentials can expire at any time). So pausing may be better > than dying. It can, but I doubt it is a big problem with smart-http. We will make a handful of quick negotiation requests at the beginning, and then the bulk of the data will come over a single http request. > However without going there: the portal page will usually be pretty simple, a > standard basic auth form, can't git handle this? If simple web clients such as > git have specific constrains on what can appear or not on this page, can you > not define them and send them ietf-side so they can document them in a later > rfc revision? Git handles http basic auth. But my experience has been that captive portals almost _never_ do basic auth. Instead, they give you an html page with a bunch of form fields. And possibly some javascript required to submit it. Git does not understand either of those things, and nor should it; spawning a browser is the right thing to do there. I don't think the IETF can or should mandate what goes on such a page. Some portals will want login/password. Some will want billing information. Some will even want other things (at some airports, I have seen captive portals offer the option to take a short survey in return for net access for a day). So it is not a matter of what git wants, but what the captive portals want. > The main impetus from my point of view is that captive portal/proxy auth is a > mess, because they try to trick web clients into displaying something they are > not prepared to and don't want to do, and this spec is replacing trick with > explicit request, which is nice. Yeah, and I think it is an improvement over the current state. Right now git will properly fail with a 511 (which is what the designers intended). I'd rather hold off on something more advanced until somebody comes forward with a concrete case and says "hey, my network gives a 511 in this instance, and here's what would be the best thing for git to do". Preferably with patches, of course. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html