Re: Feedback on Fallback
Mark Nottingham <mnot@mnot.net> Fri, 15 August 2014 02:09 UTC
Return-Path: <ietf-http-wg-request@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928B61A06E5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Aug 2014 19:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.97
X-Spam-Level:
X-Spam-Status: No, score=-6.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, 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 uwZabYTAI0W2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Aug 2014 19:09:39 -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 9E5F91A6F39 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Aug 2014 19:09:39 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XI6uJ-0005ox-Hr for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Aug 2014 02:06:19 +0000
Resent-Date: Fri, 15 Aug 2014 02:06:19 +0000
Resent-Message-Id: <E1XI6uJ-0005ox-Hr@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1XI6tv-0005ht-CL for ietf-http-wg@listhub.w3.org; Fri, 15 Aug 2014 02:05:55 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1XI6tu-0007iB-G0 for ietf-http-wg@w3.org; Fri, 15 Aug 2014 02:05:55 +0000
Received: from [192.168.1.55] (unknown [118.209.12.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0E715509B5; Thu, 14 Aug 2014 22:05:30 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <72fd1f4155804e7ab2f08dfed688fe5f@BL2PR03MB132.namprd03.prod.outlook.com>
Date: Fri, 15 Aug 2014 12:05:28 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C982811C-555D-4174-9EC1-F5CBDEC27BBA@mnot.net>
References: <72fd1f4155804e7ab2f08dfed688fe5f@BL2PR03MB132.namprd03.prod.outlook.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
X-Mailer: Apple Mail (2.1878.6)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-3.074, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1XI6tu-0007iB-G0 d0787cc1d57012b43284e754c9e4ab5a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Feedback on Fallback
Archived-At: <http://www.w3.org/mid/C982811C-555D-4174-9EC1-F5CBDEC27BBA@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26600
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>
Thanks, Mike. Just for reference, the interim discussion is minuted here: https://github.com/httpwg/wg-materials/blob/gh-pages/interim-14-06/minutes.md#tls-renegotiation ... and to make sure we track it,I'm reopening the issue: https://github.com/http2/http2-spec/issues/496 Regards, On 15 Aug 2014, at 8:56 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > Going into WGLC, we committed to implementations and taking changes based solely on implementation experience and real-world data. 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 reasoning 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 various reasons. We’ve all pushed hard against bulk-relegating any class of HTTP usage into the “They should just use 1.1” bucket, but it’s becoming clear that there will occasionally 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 way 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 published 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 the client made; Mark’s draft added semantics to inform a client what version would be acceptable, if any, so that an intelligent client could transparently 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 logs. This isn’t actually a server “failure” per se, we just used it because 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 this 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 that response. You can’t subsequently change the :status to 505. Some of these situations can occur when the 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 are not guaranteed to support it. An unsupporting client will just retry 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 browser 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 request only” button. > > On the other hand, a new error code doesn’t suffer from these issues. A RST_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 understand it and respond appropriately. > > Thus, we think an “HTTP/1.1 Required” error code will be a better option than proceeding with the Over-Version draft. -- Mark Nottingham https://www.mnot.net/
- Feedback on Fallback Mike Bishop
- Re: Feedback on Fallback Mark Nottingham
- RE: Feedback on Fallback Mike Bishop
- Re: Feedback on Fallback Ilari Liusvaara
- RE: Feedback on Fallback Mike Bishop
- #496: Feedback on Fallback Mark Nottingham
- Re: #496: Feedback on Fallback Eliot Lear
- RE: #496: Feedback on Fallback Lucas Pardue
- RE: #496: Feedback on Fallback Mike Bishop
- RE: #496: Feedback on Fallback Mike Bishop
- Re: #496: Feedback on Fallback Jason Greene
- RE: #496: Feedback on Fallback K.Morgan
- Re: #496: Feedback on Fallback Mark Nottingham