Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Kazuho Oku <kazuhooku@gmail.com> Sun, 12 November 2017 00:31 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952921274D0 for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 16:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 q5KR37I84Wat for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 16:31:46 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 BF11012704A for <hybi@ietf.org>; Sat, 11 Nov 2017 16:31:46 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id n89so9301143pfk.11 for <hybi@ietf.org>; Sat, 11 Nov 2017 16:31:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ycm0ggjwUVJ0RWmm0sU3mShfuS6mVYp29iuhYFS0LzA=; b=RYzhw5mzdcdp7zQdMU10Sle3+hKAggEUHncSkX9LsY5rgFqZAptxFzdZwry40ECNgJ Z1wUYOYPQ09HeA+WlNNKOeUbzbWLq/JMoqMTKya+LPRdYUd7qPECdur38b+vQIOhbaLK MEZQZ+kaGN42xVKI5EP+TxafmHZ6zvMgWaEFKYgfRu5RSpAkYntelEWmb/2jQmmN3Lac TtoAri4kt4IoJZ1umjAQ/OslTaPfREPR131FRK/pvlHnt4w2NnvM4wjiwv1CQOh0L8ZP pbkrYUF7ZF84vDrizdXfVCApnI32g3OW3yOZZIKayHuzK1GTq1Ks2J8yhhxxWVeyc32i mfLA==
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=ycm0ggjwUVJ0RWmm0sU3mShfuS6mVYp29iuhYFS0LzA=; b=HDhRastFI5UKevQIu+i6KVQRfwubZrVIFk7Wy6YnQN2pIXXzoRNi4NtAa+sZclCxzV vX4ZHimbSmXP/VRO+6vbpmroffrVaA1AxWWHtGG6+6IbvyapBdhrTsMgUZwnEB2zLB7T KDPmSYcLlWs9EG+dZBQSv7bQ71O3JrB2bBZzrgVyC/fFMbrwq3F4333DhEQcGJ2pYaMx 3So/7DJ0Qc+TZofngQnLb1LdfgGYkREH8d5uMTAAQXJeEnOjhJJ8ChTCQ70B2HjjUmyq C5uGs0zhCe/1gjGsxDetR5vl7/fut5e2qHy2/kcw5fbnbIsiivYhxULNrgEOE2tRU6b3 jLnA==
X-Gm-Message-State: AJaThX4Tg0wwg2FPVU4x3aEgGoYkYOD+3f1bbboqw+FCeXKhcQsBtXIt M0ZHpbkfwLpIIqhFUO2r7OBcvDXo5SE+Tlv2Kng=
X-Google-Smtp-Source: AGs4zMY3f/gRAzvcNV1zFQ3HQnxvGk0jmmJqzc1jvSQ5uZP9ZkJ2luw4SgdKtLX+r/kIU2NnVBy1uTGzewNRVPQa7fo=
X-Received: by 10.99.112.23 with SMTP id l23mr4516646pgc.277.1510446706361; Sat, 11 Nov 2017 16:31:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.159.9 with HTTP; Sat, 11 Nov 2017 16:31:45 -0800 (PST)
In-Reply-To: <201711111045.vABAjCvK027388@shell.siilo.fmi.fi>
References: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com> <20171110061456.1349EB532F@welho-filter2.welho.com> <CANatvzya831tQdWsjpiwdF537jVqZYCQpi3aFHLdQoGjShcCRw@mail.gmail.com> <CAH9hSJapY-KxFwMzGp4vmNcZuu5R8gJ+es4Rs1Le8G2CWPLjsQ@mail.gmail.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> <CAH9hSJZGN-VLLGFs46HHZSV+sWbAeh+sNC2sck-OQbi1GGK+ZQ@mail.gmail.com> <CANatvzz8YP0fDBfxSzFsRCG+q7XGpmRqsb5yy5DvHDzLdi4RAw@mail.gmail.com> <201711111045.vABAjCvK027388@shell.siilo.fmi.fi>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sun, 12 Nov 2017 08:31:45 +0800
Message-ID: <CANatvzwu=D7b+KrmQgHW+qtqXkW29bcx8_hNMT-xfcaCxNbfFg@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: Takeshi Yoshino <tyoshino@google.com>, hybi <hybi@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/VPsWxUSXbZjnl-Y8PmNR1bEGSP8>
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2017 00:31:48 -0000

Hi,

2017-11-11 18:45 GMT+08:00 Kari Hurtta <hurtta-ietf@elmme-mailer.org>;:
> Kazuho Oku <kazuhooku@gmail.com>;: (Sat Nov 11 09:46:58 2017)
> <...>
>> > We could design error code, fallback, etc. for this kind of cases if it
>> > turns out we really need to take care of. For the initial implementation,
>> > maybe we could just let browsers give up when a connection attempt fails on
>> > a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced.
>>
>> I agree.
>>
>> While I agree that having a status code that indicates failure to
>> upgrade the connection "end-to-end" might be a nice idea, I would also
>> argue that the necessity is not specific to HTTP/2.
>>
>> We could have had a connection-cannot-be-upgraded status code for
>> HTTP/1.1. But in reality, we do not have such a status code, and
>> nobody has argue for having that (as I know of).
>
> There is (sort of)
>
> 426 Upgrade Required
>
>
> normally, if Upgrade can not done, http request is processed without protocol
> change.  This status code allows refusing of processing.
>
> 426 Upgrade Required
>
> is defined on
>
> RFC 2817: Upgrading to TLS Within HTTP/1.1
> https://tools.ietf.org/html/rfc2817
>
>
> Yes, that status code is for somewhat different purpose.

Thank you for pointing that out.

My view is that 426 is a status code that instructs a client to
upgrade the connection (or a stream).

I do not think that it would be the status code that we can use for
telling the client that the stream could not be upgraded even though
the client requested the upgrade.

>
>> Considering the fact, I would anticipate that we will be fine without
>> adding a new status code to indicate such failure.
>>
>> --
>> Kazuho Oku
>
> / Kari Hurtta
>



-- 
Kazuho Oku