Re: [Captive-portals] practicality of 511 HTTP status code

To: Erik Kline <[email protected]>

Subject: Re: [Captive-portals] practicality of 511 HTTP status code

From: David Bird <[email protected]>

Date: Sun, 7 May 2017 11:36:24 -0700

Archived-at: <https://mailarchive.ietf.org/arch/msg/captive-portals/VV1_9CxEi3po9NNsPC3nHZjX9qw>

Authentication-results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com

Cc: [email protected]

Delivered-to: [email protected]

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vYCFDxcXZ5kvhLVSlogjVEpyPI/TxqhppfyfkNY33QQ=; b=buPMi6tfuqtSYn8o2qaOAYFNW1q0J6DQMQeCVTbV1smVDwRT4sSCuqJFchIrpV/Pyl 62h0NhN+aX9iC6+gDFCBPwWFBpL3gRGAOQsNN7Pl/ZnBgm4jenfzXs5QSc+zUhnvwmLZ FXp4YvpMZ9CaU/jSQYi7H75IhlYYtVxP0HvPms7OSRQSz1X+pjpRDriLVwwSKDoM1iDY S6sA2vgOrD7Jjv3LyR0WB3LHdWqjt5Q9Ou8Im2uQD3QSMyZXry/+btKT5/R+HLDi8gEQ +SYgBzZ1cQ5FCn2NGJORUCQB+UHx6796cCGDM1Uig4BUUHhlwlRgUDY16hJH4CxPwBQe O5vw==

In-reply-to: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com>

List-archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>

List-help: <mailto:[email protected]?subject=help>

List-id: Discussion of issues related to captive portals <captive-portals.ietf.org>

List-post: <mailto:[email protected]>

List-subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:[email protected]?subject=subscribe>

List-unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:[email protected]?subject=unsubscribe>

References: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com>

I personally do not find it very useful in public access networks, because:

- A legacy 30X response will still be needed for some user-agents

- Returning 511 is still a man-in-the-middle response (nothing changed there)

- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL

- differences in how browsers handle the 'error' and the associated user experience

There are a couple other oddities:

   Note that the 511 response SHOULD NOT contain a challenge or the
   login interface itself, because browsers would show the login
   interface as being associated with the originally requested URL,
   which may cause confusion.

Why shouldn't it contain a challenge? (the reason given only relates to the 'login interface itself').

   It is not intended to
   encourage deployment of captive portals -- only to limit the damage
   caused by them.

Damage? Hm... 

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline <[email protected]> wrote:

I wanted to poll the group's thoughts on the usefulness of the rfc6585#section-6 511 HTTP status code.

Has anybody tried to serve 511s to clients, and if so what were the results?

Might it be useful to serve an API endpoint (rather than the full-blown HTML UI)?

I'm trying to get a sense of whether this will be a useful tool to use in assembling a recommended portal interaction. If we determine it's not really going to be a workable component, then that's useful to know too.

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals