IETF Logo Mail Archive

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

Vincent van Dam <VvanDam@sandvine.com> Sun, 07 May 2017 18:23 UTC

Return-Path: <VvanDam@sandvine.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA4128D3E for <captive-portals@ietfa.amsl.com>; Sun, 7 May 2017 11:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 217Og52Gf6_V for <captive-portals@ietfa.amsl.com>; Sun, 7 May 2017 11:23:53 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5748C128BC8 for <captive-portals@ietf.org>; Sun, 7 May 2017 11:23:53 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Sun, 7 May 2017 14:23:51 -0400
From: Vincent van Dam <VvanDam@sandvine.com>
To: Erik Kline <ek@google.com>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] practicality of 511 HTTP status code
Thread-Index: AQHSxwjTJeG0HSprU02ArwB2QAXM4qHpL/jp
Date: Sun, 07 May 2017 18:23:50 +0000
Message-ID: <D2A19ABBC0147C40BFBB83D1CF3E95F03FEB4714@wtl-exchp-2.sandvine.com>
References: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com>
In-Reply-To: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.196.10]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_D2A19ABBC0147C40BFBB83D1CF3E95F03FEB4714wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/tYlotK1YTvKeEouYW-pl8ZZU5PQ>
Subject: Re: [Captive-portals] practicality of 511 HTTP status code
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 May 2017 18:23:58 -0000

I think the 511 fits one use-case, being the scenario where http traffic is intercepted by the nas and the user is redirected with a http 302/307 status code to a captive portal. The 511 would be, imo, the right status code to use instead of 302/307.


Since the 511 status is an error http status code; it has a higher chance of signalling unaware clients there is something wrong. The goal of the nas for intercepting the http request is to show a captive portal, and only applications that did http requests and are able to present that captive portal (webbrowsers) should gracefully handle this status code.


Since 511 is an error code; I would expect that some application doing e.g. an api call over http or fetching some static configuration file are able to better handle this than being redirected to something that can’t be interpreted (but produced a success status code). If the 511 status code would be used, the response would likely be already considered as an error because. I think it will also improve fetching resources (images/javascripts) in a the captive state, these should fail immediately as well with an error (instead of each resource returning the captive portal markup).


I am also very curious about at least the adoption and support of this status code.


________________________________
Van: Captive-portals [captive-portals-bounces@ietf.org] namens Erik Kline [ek@google.com]
Verzonden: zondag 7 mei 2017 10:05
Aan: captive-portals@ietf.org
Onderwerp: [Captive-portals] practicality of 511 HTTP status code

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.

v2.23.0 | Report a Bug | By Email