- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 21 Feb 2012 10:28:33 +0100
- To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- CC: squid3@treenet.co.nz, ietf-http-wg@w3.org, Jeff King <peff@peff.net>, git@vger.kernel.org, Daniel Stenberg <daniel@haxx.se>
On 2012-02-21 09:58, Nicolas Mailhot wrote: > > Le Dim 19 février 2012 11:22, Nicolas Mailhot a écrit : > >> 511 is exactly what I need. I was not aware of it. Is it simplemented in any >> browser yet? Where should I point the browser writers to get it implemented? >> >> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt ? > > I take that back. 511 is almost exactly what we need. However, when I pointed > the authors of some of the tools that pass through our proxy to it (curl, git) > they told me they could not parse html code in their tools, so they really > need a location (or similar) field containing the address of the > authentication portal to communicate it to the user. Without this field, they > can only stop with 'Network authentication is needed' instead of 'Please open > <url> in your browser to proceed'. Yes. The definition of status code 511 did not attempt to solve more problems than that. > http://article.gmane.org/gmane.comp.version-control.git/191085 > http://article.gmane.org/gmane.comp.version-control.git/191087 > http://article.gmane.org/gmane.comp.version-control.git/191086 > > (the nearest thing there is in the spec is the url in meta, but it's only in > the example, not mandatory, and no one will write code for something they can > not be sure will exist) > > We'd like to support those tools properly as their users' previous clumsy > attempts to navigate our current non-standard redirection method resulted in > internal security investigations. > > It is a problem in our setup as we only block some URLs (others are allowed > transparently without auth), and we use several proxy farms in different > physical sites (to avoid spofs). So just opening any url in a browser won't > trigger an authentication request (the url may not be blocked, or the browser > may pass through a gateway where the user IP is already authorized, while > git/etc tried to access through another one). > > Could you please revise the error 511 definition to add such a field ? The specification has already been approved, so it's too late to make more than editorial changes. Best regards, Julian
Received on Tuesday, 21 February 2012 09:29:13 UTC