Re: HTTP/2 Upgrade with content?

"Jason T. Greene" <jason.greene@redhat.com> Fri, 13 March 2015 08:33 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ietf.org@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 C6AE81A1AB2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 01:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 f-Z5Cp5ySZZB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 01:33:23 -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 CB4DD1A1AB4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Mar 2015 01:33:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YWKyF-0000XT-74 for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Mar 2015 08:29:27 +0000
Resent-Date: Fri, 13 Mar 2015 08:29:27 +0000
Resent-Message-Id: <E1YWKyF-0000XT-74@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <jgreene@redhat.com>) id 1YWKy7-0000WR-ME for ietf-http-wg@listhub.w3.org; Fri, 13 Mar 2015 08:29:19 +0000
Received: from mx4-phx2.redhat.com ([209.132.183.25]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <jgreene@redhat.com>) id 1YWKy5-0003ip-Rt for ietf-http-wg@w3.org; Fri, 13 Mar 2015 08:29:19 +0000
Received: from zmail15.collab.prod.int.phx2.redhat.com (zmail15.collab.prod.int.phx2.redhat.com [10.5.83.17]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t2D8Sk6S018355; Fri, 13 Mar 2015 04:28:46 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail-04295F23-83C3-4310-87C6-6BBBF55647A5"
Content-Transfer-Encoding: 7bit
From: "Jason T. Greene" <jason.greene@redhat.com>
MIME-Version: 1.0
Message-Id: <7C1D0B76-0C00-4BF4-B2D2-EE0D311B75A0@redhat.com>
Date: Fri, 13 Mar 2015 04:28:46 -0400
References: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
In-Reply-To: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Zimbra 8.0.6_GA_5922 (MobileSync - Apple-iPhone7C1/1202.466)
Thread-Topic: HTTP/2 Upgrade with content?
Thread-Index: cTLS02xflnL+Ax1vweDNMrpyFMXo9Q==
Received-SPF: pass client-ip=209.132.183.25; envelope-from=jgreene@redhat.com; helo=mx4-phx2.redhat.com
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=-0.917, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: maggie.w3.org 1YWKy5-0003ip-Rt 8a0de0b1e8d08dd8fb519626513772b2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <http://www.w3.org/mid/7C1D0B76-0C00-4BF4-B2D2-EE0D311B75A0@redhat.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28951
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 about draining the content and after the 101 the h2 response sends a 307?

> On Mar 12, 2015, at 6:14 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> 
> Section 3.2 describes the upgrade to HTTP/2 and it allows support for upgrade requests with bodies:
>    Requests that contain an entity body MUST be sent in their entirety
>    before the client can send HTTP/2 frames. This means that a large
>    request entity can block the use of the connection until it is
>    completely sent.
> Servers will need to protect themselves from DoS attacks via such requests as buffering arbitrary large content in their entirety is a commitment that servers cannot generally give.
> 
> Thus servers will have to limit the size of the entities they are prepared to hold in this situation (and the size of a single normal request buffers is probably the memory commitment they are prepared to make for any given connection).
> 
> My question is, what should a server do if it receives an otherwise valid upgrade request that it could handle but with content that exceeds this memory limit?      Should it respond with a 413 REQUEST_ENTITY_TOO_LARGE or should it just ignore the upgrade and let the request be handled via HTTP/1.1 (which can stream the content into the request handler and it becomes somebody else's problem to limit memory usage).
> 
> My problem with ignoring the upgrade is that it is an arbitrary limit and it will be hard for clients to tell why some upgrades work and others do not.
> 
> Alternately my problem with 413 is that some servers might wish to avoid the whole upgrade with content path and thus send a 413 for any upgrade with content, which may break some clients that could otherwise proceed with HTTP/1.1
> 
> thoughts?
> 
> PS. in hindsight, I would rather that we had not allowed upgrades with content and instead told clients to upgrade with an OPTION request prior to any PUT/POST request.... gallop... gallop... gallop.... SLAM!
> 
> 
> 
> -- 
> Greg Wilkins <gregw@intalio.com>  @  Webtide - an Intalio subsidiary
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com  advice and support for jetty and cometd.