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

David Bird <dbird@google.com> Tue, 27 June 2017 16:12 UTC

Return-Path: <dbird@google.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 54454129B4D for <captive-portals@ietfa.amsl.com>; Tue, 27 Jun 2017 09:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 PPU2WGWWnK8L for <captive-portals@ietfa.amsl.com>; Tue, 27 Jun 2017 09:12:22 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B2A129ABD for <captive-portals@ietf.org>; Tue, 27 Jun 2017 09:12:22 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id m84so18296262ita.0 for <captive-portals@ietf.org>; Tue, 27 Jun 2017 09:12:22 -0700 (PDT)
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=cLv3OSZGy5LdaYM1yrMBIQd3953QrrsuM64FqKgFS9E=; b=s/D25+sLZmC+8t/qzxHy09p+GD+fvE75oWaqUFGY7vGx1JzqAnMXwYa5gBM8JIuseh ikRg3uqjQrapTdoc4puvAOSPNeekJWaQlPkY6Bwq8v33N6MFjTMDzNOnXkvPSJrhex4e LgHpymPD0FCqDvbdiXdkHTj1D3sp7gbIVKAQFWHpe453phaPXqLLd43jvNaTdvlr3lut CR75Clu68OBOXo6ZnhLPV5xuC1nVuPyVRMc3+kToFqWMqQyiZWE2wlJFTI9FquEHhK3I T6FtkKmHv3GfET+kCs5Xl7yPK2YXN0aHDoaXVXQSNImGu6Jul9goPIkkGEgA771ertGm 3+oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cLv3OSZGy5LdaYM1yrMBIQd3953QrrsuM64FqKgFS9E=; b=pZRuMK5QgTjpLbJX4AgzTQ4afKEB47HVHJUAwa2OV9lxbHPJ9vSzI6XAmI8VBJgmzS jQQr804R9UoRHPWlqYmhFi+FQaXKraADEEJb86MgkRDPfeG9CGuW6i+7LvK4H34x2Gfd /HZyk43lN2a6RyjA8aeAngPXyN5wEjnYTcBU6P+63VfqC4i1EIAEeoLGrdLK0ex8kpiI EOCaefpHSeSCj0AK/paE5K+D9mkTSd2/1yO9lWD2UK+ErAN4mAwfhr8qFrSiNxh84DDU znQOiAsdeKLZgc+YF0bg3zmV01tCmwRCYtqmaHMd8ll2LQjJm1EpnBaNcNUFprUXssj9 dncw==
X-Gm-Message-State: AKS2vOwrO8C0DacHfr57NRTNExmDMaRGwK/OM8N+U4qJCRybqX2iJuWv ki/z5XAGSwICu6FRg1WKSqYq7mRZA2Fk
X-Received: by 10.36.73.82 with SMTP id z79mr3978292ita.20.1498579941490; Tue, 27 Jun 2017 09:12:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.14.144 with HTTP; Tue, 27 Jun 2017 09:12:20 -0700 (PDT)
In-Reply-To: <ab34fedc-a7c0-bba4-ccd9-6e2bc6d5a851@gmx.de>
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>
From: David Bird <dbird@google.com>
Date: Tue, 27 Jun 2017 09:12:20 -0700
Message-ID: <CADo9JyUz88kdGPc49_mkxG6yMveH7tRGr6kuANSfSM=XG1hzpw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Dave Dolson <ddolson@sandvine.com>, Mark Nottingham <mnot@mnot.net>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c147a61505330552f355fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/mQVEejYJpP8smFX1rUho5GqGly0>
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:12:24 -0000

On Tue, Jun 27, 2017 at 8:55 AM, Julian Reschke <julian.reschke@gmx.de>
wrote:

> 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?
>
> ...
>>
>
>

It would be interesting to have a review of browsers and how they handle
511. Most browsers are probably "OK" with 511, but how about the venue?
That would depend on if the user experience is broken, or not as desirable.
A venue/operator could just use javascript to redirect (if the sandboxed
browser environment allows it) as suggested, but assuming the browser
didn't otherwise 'break' the UX, how is that different from a 30X redirect?
Sure, some headless Apps making API calls might be 'broken' with unexpected
results, but do we care? Those developers should use TLS, not follow
redirects, and write robust software with exception handling..