2.2. Interaction with "https" URIs | Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Kari hurtta <hurtta-ietf@elmme-mailer.org> Sun, 09 October 2016 07:39 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2201204D9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Oct 2016 00:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Level:
X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-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 KuMDb1DTm5bO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Oct 2016 00:39:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472B41293FB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 9 Oct 2016 00:39:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bt8dK-0001e9-Nb for ietf-http-wg-dist@listhub.w3.org; Sun, 09 Oct 2016 07:34:54 +0000
Resent-Date: Sun, 09 Oct 2016 07:34:54 +0000
Resent-Message-Id: <E1bt8dK-0001e9-Nb@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1bt8dE-0001dS-OH for ietf-http-wg@listhub.w3.org; Sun, 09 Oct 2016 07:34:48 +0000
Received: from welho-filter1.welho.com ([83.102.41.23]) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1bt8dB-0001GH-CT for ietf-http-wg@w3.org; Sun, 09 Oct 2016 07:34:47 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 6A669113F0; Sun, 9 Oct 2016 10:34:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id aF1BVTj4XBLr; Sun, 9 Oct 2016 10:34:16 +0300 (EEST)
Received: from hurtta09lk.keh.iki.fi (89-27-35-245.bb.dnainternet.fi [89.27.35.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id 8207A2310; Sun, 9 Oct 2016 10:34:16 +0300 (EEST)
In-Reply-To: <BN6PR03MB27081C5CF95FB443BB4C155B87C70@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <20161004160321.DFB4C111E5@welho-filter1.welho.com> <BN6PR03MB27082C2CF4DC3F8F82354FDE87C50@BN6PR03MB2708.namprd03.prod.outlook.com> <201610050451.u954pomK003643@shell.siilo.fmi.fi> <CAOdDvNpRN_trGi23BpqUxmaLoLvom9+Yiew0GkNkhgwvqw4Bew@mail.gmail.com> <CABkgnnVKeqnyqhgL=jx1WqtcByqHes25XDJ684J+rNwvQt+znQ@mail.gmail.com> <201610051336.u95DaAW2020152@shell.siilo.fmi.fi> <CABkgnnVaBVE8mUxuGXYe-WeM_OkiNHcA=egnb1-nOxtdujShfw@mail.gmail.com> <201610051616.u95GGWcI031833@shell.siilo.fmi.fi> <BN6PR03MB2708B42C6964AA22AF8FFDC487C40@BN6PR03MB2708.namprd03.prod.outlook.com> <CABkgnnVJ7VRBH4VeGODkSUXdW9XHs8AjB_M0mm8Kt=nv3djvEg@mail.gmail.com> <BN6PR03MB27081C5CF95FB443BB4C155B87C70@BN6PR03MB2708.namprd03.prod.outlook.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Date: Sun, 9 Oct 2016 10:34:16 +0300 (EEST)
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
CC: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <mcmanus@ducksong.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha42]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20161009073417.6A669113F0@welho-filter1.welho.com>
Received-SPF: none client-ip=83.102.41.23; envelope-from=khurtta@welho.com; helo=welho-filter1.welho.com
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: AWL=-1.349, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.303, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bt8dB-0001GH-CT 3bea3579f0b5f42171bc6582cda380c0
X-Original-To: ietf-http-wg@w3.org
Subject: 2.2. Interaction with "https" URIs | Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <http://www.w3.org/mid/20161009073417.6A669113F0@welho-filter1.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32533
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> What if http://.../.w-k/h-o MUST exist (200) and https:// .../.w-k/h-o MUST NOT exist (404)?  If a client checks both of those things, it has actually proven scheme handling rather than just asked the server to promise.

( status 200 with empty /.well-known/http-opportunistic
  or html /.well-known/http-opportunistic does not
  really tell that http: -scheme is handled. It MUST
  also return application/json Content-Type and at least
  json SHOULD be parsed and verified)

So 
  GET http://www.example.com/.well-known/http-opportunistic HTTP/1.1

from origin and alternative service can be done same time. These
two MUST be same.

GET https://www.example.com/.well-known/http-opportunistic HTTP/1.1

must either use new connection or if same connection is
used first need wait that http-opportunistic is parsed
and there is "mixed-scheme" member with value "true"
for the origin "http://www.example.com/".

I think that following should be allowed for not exist:

	404 Not Found
	TBD1 Scheme Not Allowed       (this RFC)
	501 Not Implemented

I'm not sure about
	421 Misdirected Request

2.2.  Interaction with "https" URIs
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-2.3

|   Because of the risk of server confusion about individual requests'
|   schemes (see Section 4.4), clients MUST NOT send "http" requests on a
|   connection that has previously been used for "https" requests, unless
|   the http-opportunistic origin object Section 2.3 fetched over that
|   connection has a "mixed-scheme" member whose value is "true".

I think that RFC can also require opposite.

Add:

   And clients MUST NOT send "https" requests on a connection that has 
   previously been used for "http" requests, unless the http-opportunistic 
   origin object has a "mixed-scheme" member whose value is "true"

That https: not exist -check perhaps can be on that section also.

   Client MUST check that "http-opportunistic" well-known URI is
   not retriable with using "https" scheme for an alternative
   service before using for "http" origin. 

   Note: If the http-opportunistic origin object has no "mixed-scheme" 
   member with value "true", then check need to be done with different 
   connection than what was used for getting http-opportunistic response
   for "http" scheme.

   Client SHOULD NOT use selected alternative service for "http" origin
   unless "http-opportunistic" well-known URI via "https" scheme
   returned HTTP status code

     ∘ 404 (Not Found), or
     ∘ TBD1 (Scheme Not Allowed), or
     ∘ 501 (Not Implemented).

( SHOULD NOT so that there is some leeway for what 
  HTTP status codes are considered to be not existing
  resource. )

  The TBD1 (Scheme Not Allowed) status code indicates that
  used scheme is not allowed for the request.

3.  IANA Considerations
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-3

add:

  This specification registers a (HTTP) Status Codes:

  [TO BE REMOVED: Hypertext Transfer Protocol (HTTP) Status Code Registry
   http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ]

   +-------+-------------------------------+-------------+
   | Value | Description                   | Reference   |
   +-------+-------------------------------+-------------+
   | TBD1  | Scheme Not Allowed            | Section 2.2 |
   | TBD2  | Scheme Required               | Section 2.1 |
   +-------+-------------------------------+-------------+

   [TO BE REMOVED: TBD1 and TBD2 are from 4xx range. ]


I wrote at  https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0097.html

|  When client send "http" requests over a TLS connection request
|  request MUST include scheme. This means that when used with 
|  protocol identifier "http/1.1" (TTP/1.1 over TLS), request uses 
|  absoluteURI -form.

for "2.1.  Alternative Server Opt-In"
( Better title: 2.1.   Using "http" scheme over TLS connection)

This chapter can include:

  Server MAY return http status code TBD2 (Scheme Required) 
  if request does not include scheme.

  The TBD2 (Scheme Required) status code indicates
  that scheme is required for request. This means that
  server requires absoluteURI -form to be used for
  HTTP/1.1 -request.

/ Kari Hurtta