From: Jeff King <peff@peff.net>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: git@vger.kernel.org
Subject: Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
Date: Mon, 20 Feb 2012 14:30:06 -0500 [thread overview]
Message-ID: <20120220193006.GA30904@sigill.intra.peff.net> (raw)
In-Reply-To: <72fbd4155349723da1c3c503c1c9c620.squirrel@arekh.dyndns.org>
On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:
> > I think a good first step would be improving the error message for a
> > 511, then. Unfortunately, it seems from the rfc draft you sent that
> > callers are expected to parse the link out of the HTML given in the body
> > of the response. It seems silly that there is not a Location field
> > associated with a 511, similar to redirects.
>
> The URL is not lost in the HTML text, it's in the url meta field
>
> <meta http-equiv="refresh"
> content="0; url=https://login.example.net/">
Sorry, but
1. That is in the HTML in the body of the response (by body I don't
mean the HTML <body>, but the body of the http request).
2. I don't see anything in the rfc indicating that there must be a
meta tag in the response. They use it in the example of the rfc,
but they also have human-readable text with an <a> link. Do we yet
know what will be common among captive portals?
You said you have a non-hypothetical case. Can you show us the response?
> As for while there is no Location field, I think it's because otherwise it
> could behave like a redirect, and browser people made it plain they didn't
> want redirects of https accesses (but I wasn't there when the spec was
> written, and only skimmed the workgroup archives, so there may have been other
> reasons for this choice. I'm pretty sure it's deliberate anyway).
Even if they didn't call it Location, it would be nice to have some
machine-readable format that is understood by non-browser agents that
don't know how to parse HTML. But I recognize that is not your decision,
so don't feel obligated to defend it.
-Peff
next prev parent reply other threads:[~2012-02-20 19:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 21:03 Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection) Nicolas Mailhot
2012-02-20 1:06 ` Jeff King
2012-02-20 5:38 ` Nicolas Mailhot
2012-02-20 13:56 ` Jeff King
2012-02-20 15:34 ` Nicolas Mailhot
2012-02-20 15:44 ` Jeff King
2012-02-20 18:27 ` Nicolas Mailhot
2012-02-20 19:15 ` Jeff King
2012-02-20 19:24 ` Nicolas Mailhot
2012-02-20 19:30 ` Jeff King [this message]
2012-02-20 19:51 ` Nicolas Mailhot
2012-02-20 19:06 ` Daniel Stenberg
2012-02-20 19:09 ` Jeff King
2012-02-20 20:16 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120220193006.GA30904@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=nicolas.mailhot@laposte.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).