{"thread":{"id":"29669","subject":"Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","startedAt":"2012-02-19T21:03:37Z","lastAt":"2012-02-20T20:16:03Z","messageCount":14,"participants":["Nicolas Mailhot","Jeff King","Daniel Stenberg","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184951","messageId":"4b8f33ba4c870528a82ab85d6dad68bd.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":null,"subject":"Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-19T21:03:37Z","receivedAt":"2012-02-19T21:03:37Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"Since\nhttp://code.google.com/p/chromium/issues/detail?id=7338 and\nhttps://bugzilla.mozilla.org/show_bug.cgi?id=479880\n\nthere is no clean way for a proxy or captive portal to get a web client to\ndisplay an authentication dialog when user credentials expire while he is\nbrowsing on an https url.\n\n(to be sure, the previous methods were insecure and hackish but they existed\nbecause nothing better was available)\n\nThe IETF finally set up to fix this problem and defined a standard HTTP error\nthat lets access control equipments tell the web client authentication or\nre-authentication is needed and where the authentication form is located.\n\nhttp://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt\n\n→ (the\nspec is approved and in the queue for publication as RFC)\n\nPlease add error 511 handling in git, so git users that try to access external\ngit repositories over http can authenticate on the corporate proxy\n"},{"id":"184957","messageId":"20120220010617.GB4140@sigill.intra.peff.net","threadId":"29669","inReplyTo":"4b8f33ba4c870528a82ab85d6dad68bd.squirrel@arekh.dyndns.org","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T01:06:17Z","receivedAt":"2012-02-20T01:06:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:\n\n> The IETF finally set up to fix this problem and defined a standard HTTP error\n> that lets access control equipments tell the web client authentication or\n> re-authentication is needed and where the authentication form is located.\n> \n> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt\n> \n> → (the\n> spec is approved and in the queue for publication as RFC)\n> \n> Please add error 511 handling in git, so git users that try to access external\n> git repositories over http can authenticate on the corporate proxy\n\nIf I'm reading this right, the process works something like this:\n\n 1. Git wants to make a request to http://example.com\n\n 2. We make our request to a proxy server which is transparently\n proxying our traffic (i.e, a \"captive portal\").\n\n 3. The proxy returns 511 along with some URL (e.g.,\n \"http://login.corporatenetwork\"), indicating that we need\n to go to that URL to complete some authentication.\n\nAs a non-browser client, what should git do? We can't make sense of the\ncontent at http://login.corporatenetwork, which is most likely an HTML\nform asking for credentials (or even money, if the captive portal is\nsomething like a public wireless provider). The best we can probably do\nis die and say \"apparently you need to go http://login.corporatenetwork\nin a browser before making your request\".\n\nReading that rfc draft, the man impetus for non-browser clients seems\nnot to get them to do anything useful, but rather to return them a code\nthat is clearly not from the actual site (if it were a redirect, for\nexample, then we would think that example.com is redirecting is, which\nis simply not true).\n\n-Peff\n"},{"id":"184966","messageId":"9cd657a3c4960a8c496515a03bbf623e.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":"20120220010617.GB4140@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-20T05:38:54Z","receivedAt":"2012-02-20T05:38:54Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"\nLe Lun 20 février 2012 02:06, Jeff King a écrit :\n> On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:\n>\n>> The IETF finally set up to fix this problem and defined a standard HTTP\n>> error\n>> that lets access control equipments tell the web client authentication or\n>> re-authentication is needed and where the authentication form is located.\n>>\n>> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt\n>>\n>> → \n>> (the\n>> spec is approved and in the queue for publication as RFC)\n>>\n>> Please add error 511 handling in git, so git users that try to access\n>> external\n>> git repositories over http can authenticate on the corporate proxy\n>\n> If I'm reading this right, the process works something like this:\n>\n> 1. Git wants to make a request to http://example.com\n>\n> 2. We make our request to a proxy server which is transparently\n> proxying our traffic (i.e, a \"captive portal\").\n>\n> 3. The proxy returns 511 along with some URL (e.g.,\n> \"http://login.corporatenetwork\"), indicating that we need\n> to go to that URL to complete some authentication.\n>\n> As a non-browser client, what should git do? We can't make sense of the\n> content at http://login.corporatenetwork, which is most likely an HTML\n> form asking for credentials (or even money, if the captive portal is\n> something like a public wireless provider). The best we can probably do\n> is die and say \"apparently you need to go http://login.corporatenetwork\n> in a browser before making your request\".\n\nActually, the best would be to launch something capable of interpreting html\nforms on the url given by the error. But short of that, that depends on how\ngood git is at resuming work later. Error 511 can occur at any time, not just\non initial connection (because credentials can expire at any time). So pausing\nmay be better than dying.\n\nHowever without going there: the portal page will usually be pretty simple, a\nstandard basic auth form, can't git handle this? If simple web clients such as\ngit have specific constrains on what can appear or not on this page, can you\nnot define them and send them ietf-side so they can document them in a later\nrfc revision?\n\n> Reading that rfc draft, the man impetus for non-browser clients seems\n> not to get them to do anything useful, but rather to return them a code\n> that is clearly not from the actual site (if it were a redirect, for\n> example, then we would think that example.com is redirecting is, which\n> is simply not true).\n\nThe main impetus from my point of view is that captive portal/proxy auth is a\nmess, because they try to trick web clients into displaying something they are\nnot prepared to and don't want to do, and this spec is replacing trick with\nexplicit request, which is nice.\n\nBest regards,\n\n-- \nNicolas Mailhot\n"},{"id":"184989","messageId":"20120220135639.GA5131@sigill.intra.peff.net","threadId":"29669","inReplyTo":"9cd657a3c4960a8c496515a03bbf623e.squirrel@arekh.dyndns.org","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T13:56:39Z","receivedAt":"2012-02-20T13:56:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 20, 2012 at 06:38:54AM +0100, Nicolas Mailhot wrote:\n\n> > As a non-browser client, what should git do? We can't make sense of the\n> > content at http://login.corporatenetwork, which is most likely an HTML\n> > form asking for credentials (or even money, if the captive portal is\n> > something like a public wireless provider). The best we can probably do\n> > is die and say \"apparently you need to go http://login.corporatenetwork\n> > in a browser before making your request\".\n> \n> Actually, the best would be to launch something capable of interpreting html\n> forms on the url given by the error.\n\nDoing that portably is near impossible (keep in mind that git runs on\nthings like antique versions of Solaris). Not to mention that git is\noften running without a user present, or on a remote system connected\nto the user only by ssh. So our best bet would probably be a\nconfiguration option to tell git how to run a browser. Distributions\nwhich ship binary packages could ship a sane default for their system.\n\n> But short of that, that depends on how good git is at resuming work\n> later. Error 511 can occur at any time, not just on initial connection\n> (because credentials can expire at any time). So pausing may be better\n> than dying.\n\nIt can, but I doubt it is a big problem with smart-http. We will make a\nhandful of quick negotiation requests at the beginning, and then the\nbulk of the data will come over a single http request.\n\n> However without going there: the portal page will usually be pretty simple, a\n> standard basic auth form, can't git handle this? If simple web clients such as\n> git have specific constrains on what can appear or not on this page, can you\n> not define them and send them ietf-side so they can document them in a later\n> rfc revision?\n\nGit handles http basic auth. But my experience has been that captive\nportals almost _never_ do basic auth. Instead, they give you an html\npage with a bunch of form fields. And possibly some javascript required\nto submit it. Git does not understand either of those things, and nor\nshould it; spawning a browser is the right thing to do there.\n\nI don't think the IETF can or should mandate what goes on such a page.\nSome portals will want login/password. Some will want billing\ninformation. Some will even want other things (at some airports, I have\nseen captive portals offer the option to take a short survey in return\nfor net access for a day). So it is not a matter of what git wants, but\nwhat the captive portals want.\n\n> The main impetus from my point of view is that captive portal/proxy auth is a\n> mess, because they try to trick web clients into displaying something they are\n> not prepared to and don't want to do, and this spec is replacing trick with\n> explicit request, which is nice.\n\nYeah, and I think it is an improvement over the current state. Right now\ngit will properly fail with a 511 (which is what the designers\nintended). I'd rather hold off on something more advanced until somebody\ncomes forward with a concrete case and says \"hey, my network gives a 511\nin this instance, and here's what would be the best thing for git to\ndo\". Preferably with patches, of course. :)\n\n-Peff\n"},{"id":"184999","messageId":"e1d3ddd965eb32717163aaa87fa71e17.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":"20120220135639.GA5131@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-20T15:34:19Z","receivedAt":"2012-02-20T15:34:19Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"\nLe Lun 20 février 2012 14:56, Jeff King a écrit :\n> On Mon, Feb 20, 2012 at 06:38:54AM +0100, Nicolas Mailhot wrote:\n>\n>> > As a non-browser client, what should git do? We can't make sense of the\n>> > content at http://login.corporatenetwork, which is most likely an HTML\n>> > form asking for credentials (or even money, if the captive portal is\n>> > something like a public wireless provider). The best we can probably do\n>> > is die and say \"apparently you need to go http://login.corporatenetwork\n>> > in a browser before making your request\".\n>>\n>> Actually, the best would be to launch something capable of interpreting html\n>> forms on the url given by the error.\n>\n> Doing that portably is near impossible (keep in mind that git runs on\n> things like antique versions of Solaris).\n\nCan't the you let the user specify a browser command (firefox, elinks w3m) to\nauto-feed the portal page to when needed ?\n\nThe main problem with captive portals is when they shut down the connection\nand the user has no idea how to restore it (and error 511 is intended to fix\nthis, but that won't do a lot of good if the user does is not shown the\ncaptive portal url transmitted with the error)\n\nRegards,\n\n-- \nNicolas Mailhot\n"},{"id":"185000","messageId":"20120220154452.GA27456@sigill.intra.peff.net","threadId":"29669","inReplyTo":"e1d3ddd965eb32717163aaa87fa71e17.squirrel@arekh.dyndns.org","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T15:44:52Z","receivedAt":"2012-02-20T15:44:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 20, 2012 at 04:34:19PM +0100, Nicolas Mailhot wrote:\n\n> >> Actually, the best would be to launch something capable of interpreting html\n> >> forms on the url given by the error.\n> >\n> > Doing that portably is near impossible (keep in mind that git runs on\n> > things like antique versions of Solaris).\n> \n> Can't the you let the user specify a browser command (firefox, elinks w3m) to\n> auto-feed the portal page to when needed ?\n\nYes, that's why I said \"we could add a configuration option\" in the part\nthat you snipped. But doing it out of the box is not going to be\nportable.\n\n> The main problem with captive portals is when they shut down the connection\n> and the user has no idea how to restore it (and error 511 is intended to fix\n> this, but that won't do a lot of good if the user does is not shown the\n> captive portal url transmitted with the error)\n\nIn my experience, the captive portal process usually goes like this:\n\n 1. Connect to network.\n\n 2. Try some non-browser command. Wonder why in the world it isn't\n working.\n\n 3. Open a browser and say \"Ah, I see. A captive portal\".\n\nThe 511 proposal makes step 2 a lot better if the protocol is http[1].\nBut it pretty much makes it better even without non-browser client\nsupport, because at least you will get a 511 error instead of having git\ncomplain that the remote repository is corrupted (which happens if the\ncaptive portal returns a redirect to an html page).\n\nWe should already be doing that. Adding more support could make step 3 a\nlittle nicer, but like I said, I'd be more interested in seeing a real\ncase first. It may even be a feature that would be more appropriate to\ncurl (which git builds on for http access).\n\n-Peff\n\n[1] Of course it doesn't help at all for git:// or ssh:// (which are\n usually even worse off in the first place, as many captive portals\n will simply drop the packets, making it look like the remote server\n is down).\n"},{"id":"185002","messageId":"cb81840f853a1d43a7da03ea24c86445.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":"20120220154452.GA27456@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-20T18:27:08Z","receivedAt":"2012-02-20T18:27:08Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"\nLe Lun 20 février 2012 16:44, Jeff King a écrit :\n\n> In my experience, the captive portal process usually goes like this:\n>\n> 1. Connect to network.\n>\n> 2. Try some non-browser command. Wonder why in the world it isn't\n> working.\n>\n> 3. Open a browser and say \"Ah, I see. A captive portal\".\n>\n> The 511 proposal makes step 2 a lot better if the protocol is http[1].\n> But it pretty much makes it better even without non-browser client\n> support, because at least you will get a 511 error instead of having git\n> complain that the remote repository is corrupted (which happens if the\n> captive portal returns a redirect to an html page).\n>\n> We should already be doing that. Adding more support could make step 3 a\n> little nicer, but like I said, I'd be more interested in seeing a real\n> case first. It may even be a feature that would be more appropriate to\n> curl (which git builds on for http access).\n\nStep 3 is a quite less obvious on a corporate network, where Internet access\nis gated by a filtering proxy, that will let some sites pass transparently but\nrequire credentials to let you access others. Worst case, there are several\nload-balanced gateways on different physical sites (to avoid spofs in case of\nplanes falling on the wrong place), that do not share authentication (because\npropagating auth across physical sites is hard). So no, just launching a\nbrowser is not sufficient to find the captive portal, you need to actually\naccess the URL returned by error 511 in meta information. Git should at\nminimum report this URL.\n\n(and no this is not an hypothetical scenario and yes there are git users\ntrying to pass the gateways there)\n\n-- \nNicolas Mailhot\n"},{"id":"185007","messageId":"alpine.DEB.2.00.1202202002330.28090@tvnag.unkk.fr","threadId":"29669","inReplyTo":"20120220154452.GA27456@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2012-02-20T19:06:46Z","receivedAt":"2012-02-20T19:06:46Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Mon, 20 Feb 2012, Jeff King wrote:\n\n> 3. Open a browser and say \"Ah, I see. A captive portal\".\n>\n> We should already be doing that. Adding more support could make step 3 a \n> little nicer, but like I said, I'd be more interested in seeing a real case \n> first. It may even be a feature that would be more appropriate to curl \n> (which git builds on for http access).\n\nWe're already discussing the 511 in the curl camp as well, but with even more \nsighs and hands in the air. 511 is clearly intended for HTML-understanding \nuser agents and curl is not one of those. IMHO, curl will remain to simply \nhelp users to figure out that it is 511 and leave it at that.\n\nAs a git user, I would probably be very surprised if using 'git' suddenly \ncaused by browser to pop up a captive portal login. I would prefer git to \ninstead properly explain to me that is being the victim of a 511 and what I \nshould do to fix it.\n\n-- \n\n / daniel.haxx.se\n"},{"id":"185005","messageId":"20120220190939.GA29158@sigill.intra.peff.net","threadId":"29669","inReplyTo":"alpine.DEB.2.00.1202202002330.28090@tvnag.unkk.fr","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T19:09:39Z","receivedAt":"2012-02-20T19:09:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 20, 2012 at 08:06:46PM +0100, Daniel Stenberg wrote:\n\n> > 3. Open a browser and say \"Ah, I see. A captive portal\".\n> >\n> >We should already be doing that. Adding more support could make\n> >step 3 a little nicer, but like I said, I'd be more interested in\n> >seeing a real case first. It may even be a feature that would be\n> >more appropriate to curl (which git builds on for http access).\n> \n> We're already discussing the 511 in the curl camp as well, but with\n> even more sighs and hands in the air. 511 is clearly intended for\n> HTML-understanding user agents and curl is not one of those. IMHO,\n> curl will remain to simply help users to figure out that it is 511\n> and leave it at that.\n\nThanks for the input. It sounds like our best bet is to just report the\nURL from a 511 better, then. Do you have any idea yet how that\ninformation will be available to curl library users?\n\n> As a git user, I would probably be very surprised if using 'git'\n> suddenly caused by browser to pop up a captive portal login. I would\n> prefer git to instead properly explain to me that is being the victim\n> of a 511 and what I should do to fix it.\n\nI agree. Even if the \"step 3\" in my list is \"then the user starts a\nbrowser given the URL from git's error message\", that is a huge\nimprovement over the current state. And it retains the principle of\nleast surprise.\n\n-Peff\n"},{"id":"185006","messageId":"20120220191500.GA29228@sigill.intra.peff.net","threadId":"29669","inReplyTo":"cb81840f853a1d43a7da03ea24c86445.squirrel@arekh.dyndns.org","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T19:15:00Z","receivedAt":"2012-02-20T19:15:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 20, 2012 at 07:27:08PM +0100, Nicolas Mailhot wrote:\n\n> Step 3 is a quite less obvious on a corporate network, where Internet access\n> is gated by a filtering proxy, that will let some sites pass transparently but\n> require credentials to let you access others. Worst case, there are several\n> load-balanced gateways on different physical sites (to avoid spofs in case of\n> planes falling on the wrong place), that do not share authentication (because\n> propagating auth across physical sites is hard). So no, just launching a\n> browser is not sufficient to find the captive portal, you need to actually\n> access the URL returned by error 511 in meta information. Git should at\n> minimum report this URL.\n> \n> (and no this is not an hypothetical scenario and yes there are git users\n> trying to pass the gateways there)\n\nThis is exactly the sort of information I wanted to get from a\nreal-world scenario. From your initial messages, it sounded like a\npurely hypothetical thing.\n\nI think a good first step would be improving the error message for a\n511, then. Unfortunately, it seems from the rfc draft you sent that\ncallers are expected to parse the link out of the HTML given in the body\nof the response. It seems silly that there is not a Location field\nassociated with a 511, similar to redirects.\n\n-Peff\n"},{"id":"185008","messageId":"72fbd4155349723da1c3c503c1c9c620.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":"20120220191500.GA29228@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-20T19:24:15Z","receivedAt":"2012-02-20T19:24:15Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"\nLe Lun 20 février 2012 20:15, Jeff King a écrit :\n> On Mon, Feb 20, 2012 at 07:27:08PM +0100, Nicolas Mailhot wrote:\n>\n>> Step 3 is a quite less obvious on a corporate network, where Internet access\n>> is gated by a filtering proxy, that will let some sites pass transparently\n>> but\n>> require credentials to let you access others. Worst case, there are several\n>> load-balanced gateways on different physical sites (to avoid spofs in case\n>> of\n>> planes falling on the wrong place), that do not share authentication\n>> (because\n>> propagating auth across physical sites is hard). So no, just launching a\n>> browser is not sufficient to find the captive portal, you need to actually\n>> access the URL returned by error 511 in meta information. Git should at\n>> minimum report this URL.\n>>\n>> (and no this is not an hypothetical scenario and yes there are git users\n>> trying to pass the gateways there)\n>\n> This is exactly the sort of information I wanted to get from a\n> real-world scenario. From your initial messages, it sounded like a\n> purely hypothetical thing.\n>\n> I think a good first step would be improving the error message for a\n> 511, then. Unfortunately, it seems from the rfc draft you sent that\n> callers are expected to parse the link out of the HTML given in the body\n> of the response. It seems silly that there is not a Location field\n> associated with a 511, similar to redirects.\n\nThe URL is not lost in the HTML text, it's in the url meta field\n\n\n\nAs for while there is no Location field, I think it's because otherwise it\ncould behave like a redirect, and browser people made it plain they didn't\nwant redirects of https accesses (but I wasn't there when the spec was\nwritten, and only skimmed the workgroup archives, so there may have been other\nreasons for this choice. I'm pretty sure it's deliberate anyway).\n\nRegards,\n\n-- \nNicolas Mailhot\n"},{"id":"185009","messageId":"20120220193006.GA30904@sigill.intra.peff.net","threadId":"29669","inReplyTo":"72fbd4155349723da1c3c503c1c9c620.squirrel@arekh.dyndns.org","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T19:30:06Z","receivedAt":"2012-02-20T19:30:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:\n\n> > I think a good first step would be improving the error message for a\n> > 511, then. Unfortunately, it seems from the rfc draft you sent that\n> > callers are expected to parse the link out of the HTML given in the body\n> > of the response. It seems silly that there is not a Location field\n> > associated with a 511, similar to redirects.\n> \n> The URL is not lost in the HTML text, it's in the url meta field\n> \n> content=\"0; url=https://login.example.net/\">\n\nSorry, but\n\n 1. That is in the HTML in the body of the response (by body I don't\n mean the HTML , but the body of the http request).\n\n 2. I don't see anything in the rfc indicating that there must be a\n meta tag in the response. They use it in the example of the rfc,\n but they also have human-readable text with an link. Do we yet\n know what will be common among captive portals?\n\nYou said you have a non-hypothetical case. Can you show us the response?\n\n> As for while there is no Location field, I think it's because otherwise it\n> could behave like a redirect, and browser people made it plain they didn't\n> want redirects of https accesses (but I wasn't there when the spec was\n> written, and only skimmed the workgroup archives, so there may have been other\n> reasons for this choice. I'm pretty sure it's deliberate anyway).\n\nEven if they didn't call it Location, it would be nice to have some\nmachine-readable format that is understood by non-browser agents that\ndon't know how to parse HTML. But I recognize that is not your decision,\nso don't feel obligated to defend it.\n\n-Peff\n"},{"id":"185012","messageId":"12ec87a8c95ca12c22f05e1ec961d326.squirrel@arekh.dyndns.org","threadId":"29669","inReplyTo":"20120220193006.GA30904@sigill.intra.peff.net","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2012-02-20T19:51:11Z","receivedAt":"2012-02-20T19:51:11Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"\nLe Lun 20 février 2012 20:30, Jeff King a écrit :\n> On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:\n>\n>> > I think a good first step would be improving the error message for a\n>> > 511, then. Unfortunately, it seems from the rfc draft you sent that\n>> > callers are expected to parse the link out of the HTML given in the body\n>> > of the response. It seems silly that there is not a Location field\n>> > associated with a 511, similar to redirects.\n>>\n>> The URL is not lost in the HTML text, it's in the url meta field\n>>\n>> > content=\"0; url=https://login.example.net/\">\n>\n> Sorry, but\n>\n> 1. That is in the HTML in the body of the response (by body I don't\n> mean the HTML , but the body of the http request).\n>\n> 2. I don't see anything in the rfc indicating that there must be a\n> meta tag in the response. They use it in the example of the rfc,\n> but they also have human-readable text with an link. Do we yet\n> know what will be common among captive portals?\n>\n> You said you have a non-hypothetical case. Can you show us the response?\n\nNot yet because it's currently non-standard custom redirection mess we're\nrepurposing to follow the ietf spec (got tired of being accused of running a\ncrap non-standard proxy by users, so now it's ll be a crap standard proxy)\n\nThe proxy response is totally configurable (a so there's no reason we won't\nfollow the new spec to the letter\n\n\n-- \nNicolas Mailhot\n"},{"id":"185018","messageId":"7v8vjxl0qk.fsf@alter.siamese.dyndns.org","threadId":"29669","inReplyTo":"alpine.DEB.2.00.1202202002330.28090@tvnag.unkk.fr","subject":"Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-20T20:16:03Z","receivedAt":"2012-02-20T20:16:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Stenberg writes:\n\n> As a git user, I would probably be very surprised if using 'git'\n> suddenly caused by browser to pop up a captive portal login. I would\n> prefer git to instead properly explain to me that is being the victim\n> of a 511 and what I should do to fix it.\n\nI agree what you envisioned, nothing more, nothing less, is the ideal\nsolution.\n\nThanks.\n"}]}