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

Dave Dolson <ddolson@sandvine.com> Tue, 27 June 2017 16:18 UTC

Return-Path: <ddolson@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 D450F129B9C for <captive-portals@ietfa.amsl.com>; Tue, 27 Jun 2017 09:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aWQTaswvxBOs for <captive-portals@ietfa.amsl.com>; Tue, 27 Jun 2017 09:18:44 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95930129B4D for <captive-portals@ietf.org>; Tue, 27 Jun 2017 09:18:44 -0700 (PDT)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 27 Jun 2017 12:18:42 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>
CC: "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] practicality of 511 HTTP status code
Thread-Index: AQHSxwjSIR4ujCHIEk2JPkRI6Cld3aHpdqUAgAAJPICASYFSsIAAUnSA//++cpCAALY5gIAFT3VAgABY04D//8NqTw==
Date: Tue, 27 Jun 2017 16:18:42 +0000
Message-ID: <20170627161841.5161041.96743.20299@sandvine.com>
References: <CAAedzxrPo+qSBWP23=fpwG0ZzBrdOMgs0gykAxOPSFbojeR79A@mail.gmail.com> <CADo9JyVrO6fcOtYXc=VtrfmhFsYdHY=3t4nM2xLG3CBnzizWJQ@mail.gmail.com> <D2A19ABBC0147C40BFBB83D1CF3E95F03FEB4A22@wtl-exchp-2.sandvine.com> <E8355113905631478EFF04F5AA706E987061F965@wtl-exchp-1.sandvine.com> <6c04ed2c-9d26-eb9d-b4e3-5205845d0fa4@gmx.de> <E8355113905631478EFF04F5AA706E987061FA7F@wtl-exchp-1.sandvine.com> <C1A75CC1-696D-4C9D-BF97-4835BB82DEA3@mnot.net> <E8355113905631478EFF04F5AA706E9870624A0B@wtl-exchp-1.sandvine.com>, <ab34fedc-a7c0-bba4-ccd9-6e2bc6d5a851@gmx.de>
In-Reply-To: <ab34fedc-a7c0-bba4-ccd9-6e2bc6d5a851@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/7w59VYqMe9ggdwBKoAtA6259CHg>
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: Tue, 27 Jun 2017 16:18:46 -0000

Regardless of how 511 is handled, I think it is orthogonal to the work at hand. It only helps with the clear-text http, which I think operators would be resistant to change.



David Dolson
Sandvine
  Original Message
From: Julian Reschke
Sent: Tuesday, June 27, 2017 11:55 AM
To: Dave Dolson; Mark Nottingham
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] practicality of 511 HTTP status code


On 2017-06-27 16:56, Dave Dolson wrote:
> Mark, thanks for the info about 511.
>
> But to the working group, I think this discussion about HTTP status codes is a distraction.
>
> I think the ICMP approach is a superior solution that doesn't require modification of transport-layer data.
>
> Redirection of clear-text HTTP is an existing practice. It will continue for some time;

Yes.

> but there is no need to tweak it, since tweaks would not be recognized by existing software anyhow...

Existing software == browsers? They should be totally OK with 511. Do
you have evidence to the contrary?

> ...

Best regards, Julian