Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C825F1A894A for ; Thu, 14 Aug 2014 16:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HCPzSx5MKYkZ for ; Thu, 14 Aug 2014 16:00:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6ABB1A88EB for ; Thu, 14 Aug 2014 16:00:28 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1XI3xJ-0005Lm-UY for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Aug 2014 22:57:13 +0000 Resent-Date: Thu, 14 Aug 2014 22:57:13 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1XI3wq-0005Ke-HL for ietf-http-wg@listhub.w3.org; Thu, 14 Aug 2014 22:56:44 +0000 Received: from mail-bn1lp0141.outbound.protection.outlook.com ([207.46.163.141] helo=na01-bn1-obe.outbound.protection.outlook.com) by maggie.w3.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XI3wo-0006HU-CK for ietf-http-wg@w3.org; Thu, 14 Aug 2014 22:56:44 +0000 Received: from BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) by BL2PR03MB129.namprd03.prod.outlook.com (10.255.230.20) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Thu, 14 Aug 2014 22:56:14 +0000 Received: from BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.215]) by BL2PR03MB132.namprd03.prod.outlook.com ([169.254.9.215]) with mapi id 15.00.1005.008; Thu, 14 Aug 2014 22:56:14 +0000 From: Mike Bishop To: HTTP Working Group Thread-Topic: Feedback on Fallback Thread-Index: Ac+4EKcMsRBYwrwPRqiO9BW4OtDgTg== Date: Thu, 14 Aug 2014 22:56:14 +0000 Message-ID: <72fd1f4155804e7ab2f08dfed688fe5f@BL2PR03MB132.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(189002)(107046002)(107886001)(83072002)(87936001)(86612001)(95666004)(16236675004)(85852003)(2656002)(21056001)(46102001)(76482001)(31966008)(110136001)(229853001)(4396001)(92566001)(86362001)(77096002)(99286002)(105586002)(33646002)(106356001)(15975445006)(19580395003)(19617315012)(19625215002)(76576001)(101416001)(54356999)(50986999)(74316001)(19300405004)(77982001)(79102001)(85306004)(99396002)(83322001)(74502001)(74662001)(108616004)(64706001)(80022001)(81542001)(15202345003)(20776003)(81342001)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB129; H:BL2PR03MB132.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_72fd1f4155804e7ab2f08dfed688fe5fBL2PR03MB132namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Received-SPF: pass client-ip=207.46.163.141; envelope-from=Michael.Bishop@microsoft.com; helo=na01-bn1-obe.outbound.protection.outlook.com X-W3C-Hub-Spam-Status: No, score=-3.1 X-W3C-Hub-Spam-Report: AWL=-3.088, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1XI3wo-0006HU-CK 094d520d0c92a7a7ab35146f16211b88 X-Original-To: ietf-http-wg@w3.org Subject: Feedback on Fallback Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/26599 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --_000_72fd1f4155804e7ab2f08dfed688fe5fBL2PR03MB132namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Going into WGLC, we committed to implementations and taking changes based s= olely on implementation experience and real-world data. Based on our exper= ience so far, Microsoft's first piece of WGLC feedback is to replace Mark's= Over-Version draft with an error code in the spec. Our reasoning follows. As we continue to work on HTTP/2, one item that has come up repeatedly is t= he need to force clients back to HTTP/1.1 for various reasons. We've all p= ushed hard against bulk-relegating any class of HTTP usage into the "They s= hould just use 1.1" bucket, but it's becoming clear that there will occasio= nally be situations where a server needs a client to fall back. Some apps we support depend on the ability to emit raw HTTP protocol text. = Others require client certs as a matter of local law and we don't have a w= ay to retrieve the client cert without renegotiation. Others are strictly = situational, features that require adaptation work we haven't gotten to yet= . These assorted situations motivated the Over-Version draft which Mark publi= shed after the NYC Interim. 505 was already defined as meaning the server = was unable/unwilling to use the current HTTP version to serve the request t= he client made; Mark's draft added semantics to inform a client what versio= n would be acceptable, if any, so that an intelligent client could transpar= ently retry over the correct HTTP version (be it 1.1 or 3.5). We've found a couple limitations with this approach: * As Jeff pointed out in NYC, returning a 5XX looks bad in server l= ogs. This isn't actually a server "failure" per se, we just used it becaus= e the status code already exists in the 5XX range. Not a technical issue, = but definitely an operational one. (Jeff noted in NYC that there are other= 5XX status codes that Twitter non-standardly recasts in other ranges for t= his reason. New 4XX and 3XX codes were proposed as part of this discussion= , demonstrating that the concept doesn't bucket well as a status code.) * Once the HEADERS frame with :status is sent, we're locked in to t= hat response. You can't subsequently change the :status to 505. Some of t= hese situations can occur when the response is partially-generated, which l= eaves us stuck unless we buffer all responses until they're complete (unacc= eptable for perf). * Because Over-Version is optional, clients are not guaranteed to s= upport it. An unsupporting client will just retry the same request over HT= TP/2 again and never be able to obtain an actual response from the server. = Including a response body with the 505 telling clients to turn off HTTP/2 = in their browser is definitely not a direction we want to go in these situa= tions, and I don't expect clients to have a "turn off HTTP/2 for this reque= st only" button. On the other hand, a new error code doesn't suffer from these issues. A RS= T_STREAM can be sent at any point and doesn't necessarily confuse existing = heuristics. A GOAWAY with the same error code provides a clean way for the= server to transition a client to HTTP/1.1 entirely, if necessary. If it's= in the base spec, we can be assured that any client will be able to unders= tand it and respond appropriately. Thus, we think an "HTTP/1.1 Required" error code will be a better option th= an proceeding with the Over-Version draft. --_000_72fd1f4155804e7ab2f08dfed688fe5fBL2PR03MB132namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Going into WGLC, we committed to implementations and= taking changes based solely on implementation experience and real-world da= ta.  Based on our experience so far, Microsoft’s first piece of = WGLC feedback is to replace Mark’s Over-Version draft with an error code in the spec.  Our reasonin= g follows.

 

As we continue to work on HTTP/2, one item that has = come up repeatedly is the need to force clients back to HTTP/1.1 for variou= s reasons.  We’ve all pushed hard against bulk-relegating any cl= ass of HTTP usage into the “They should just use 1.1” bucket, but it’s becoming clear that there will occas= ionally be situations where a server needs a client to fall back.

 

Some apps we support depend on the ability to emit r= aw HTTP protocol text.  Others require client certs as a matter of loc= al law and we don’t have a way to retrieve the client cert without re= negotiation.  Others are strictly situational, features that require adaptation work we haven’t gotten to yet.=

 

These assorted situations motivated the Over-Version= draft which Mark published after the NYC Interim.  505 was already de= fined as meaning the server was unable/unwilling to use the current HTTP ve= rsion to serve the request the client made; Mark’s draft added semantics to inform a client what version woul= d be acceptable, if any, so that an intelligent client could transparen= tly retry over the correct HTTP version (be it 1.1 or 3.5).

 

We’ve found a couple limitations with this app= roach:

·         As Jeff pointed out in NYC, returning a 5XX = looks bad in server logs.  This isn’t actually a server “f= ailure” per se, we just used it because the status code already exist= s in the 5XX range.  Not a technical issue, but definitely an operational one.  (Jeff noted in NYC that there are other 5XX stat= us codes that Twitter non-standardly recasts in other ranges for this reaso= n.  New 4XX and 3XX codes were proposed as part of this discussion, de= monstrating that the concept doesn’t bucket well as a status code.)

·         Once the HEADERS frame with :status is sent,= we’re locked in to that response.  You can’t subsequently= change the :status to 505.  Some of these situations can occur when t= he response is partially-generated, which leaves us stuck unless we buffer all responses until they’re complete (unacceptable = for perf).

·         Because Over-Version is optional, clients ar= e not guaranteed to support it.  An unsupporting client will just retr= y the same request over HTTP/2 again and never be able to obtain an actual = response from the server.  Including a response body with the 505 telling clients to turn off HTTP/2 in their b= rowser is definitely not a direction we want to go in these situations, and= I don’t expect clients to have a “turn off HTTP/2 for this req= uest only” button.

 

On the other hand, a new error code doesn’t su= ffer from these issues.  A RST_STREAM can be sent at any point and doe= sn’t necessarily confuse existing heuristics.  A GOAWAY with the= same error code provides a clean way for the server to transition a client to HTTP/1.1 entirely, if necessary.  If it’= s in the base spec, we can be assured that any client will be able to under= stand it and respond appropriately.

 

Thus, we think an “HTTP/1.1 Required” er= ror code will be a better option than proceeding with the Over-Version draf= t.

 

--_000_72fd1f4155804e7ab2f08dfed688fe5fBL2PR03MB132namprd03pro_--