Re: HTTP/2 Upgrade with content?

Greg Wilkins <gregw@intalio.com> Fri, 13 March 2015 22:19 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 03CB01A87C2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 15:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level:
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 6fXrzhUg7-sh for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Mar 2015 15:19:30 -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 18E9D1A1E0B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Mar 2015 15:19:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YWXs2-0005Vd-HO for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Mar 2015 22:15:54 +0000
Resent-Date: Fri, 13 Mar 2015 22:15:54 +0000
Resent-Message-Id: <E1YWXs2-0005Vd-HO@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <gregw@intalio.com>) id 1YWXrs-0005Qu-AF for ietf-http-wg@listhub.w3.org; Fri, 13 Mar 2015 22:15:44 +0000
Received: from mail-la0-f50.google.com ([209.85.215.50]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <gregw@intalio.com>) id 1YWXrq-0007jI-22 for ietf-http-wg@w3.org; Fri, 13 Mar 2015 22:15:44 +0000
Received: by lamx15 with SMTP id x15so185561lam.3 for <ietf-http-wg@w3.org>; Fri, 13 Mar 2015 15:15:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R0MfvVx1RMsS7HUyNzH1PumHEX3zYAzaLcgMYdA3DFk=; b=aAQG7j/Sd7Pp81WJ0oXD5DEvwFo7joIl0OCOjVAsGgccyS1/9n0NYGY7ifGZKB0j1f kCUO9iuIBnJYDRbLRHIpf4JKV+SF456xGaQiyhXWoI3ZHLcydNm5qN5DP5UAbNbIA7Mm Af59L0cityVlDvlv+fu12l6q+duva5cQsIY4buRUngiR4YghL77rqzuYZg1PKzw/0O4w imrMr3vTPB0oU8/uFjoJc7ErUpW+ChKzfLuJMXSspLp63uDDosTG5Z9jFp1v/kUmjTwD iCqFkGk0QaFbosEGYM3Rjw4XjSCwvTmVAfxnt0ettx7A/DhX4/335BuoQd6GdndPicgn tNvg==
X-Gm-Message-State: ALoCoQm71QH3Lum1Rupqcvnd3z2U+B0uexTnU7rnXpP1+Do7Wl7rE+LQM9km29RJz5srmCqsI8QX
MIME-Version: 1.0
X-Received: by 10.152.1.194 with SMTP id 2mr21053874lao.38.1426284914362; Fri, 13 Mar 2015 15:15:14 -0700 (PDT)
Received: by 10.114.175.43 with HTTP; Fri, 13 Mar 2015 15:15:14 -0700 (PDT)
In-Reply-To: <CABkgnnWEx4+o34h70168ZYihs9MFZQ=SNQekNX1gdjq51=-k7g@mail.gmail.com>
References: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com> <BL2PR03MB1323474B977B051738AD09187060@BL2PR03MB132.namprd03.prod.outlook.com> <CAH_y2NFV=Z7hqbtWTdiePRwUnhhRjiP8R_Ua7kmpZEkwXtxgEA@mail.gmail.com> <B5C01B7A-9215-4268-B189-E6281F425BF7@greenbytes.de> <alpine.DEB.2.11.1503130833190.13706@tvnag.unkk.fr> <6E036F2D-AED0-4323-ACCB-D8036168E6C1@redhat.com> <CAH_y2NFjb0mx8Rs+qg6uJ=zgUzHW3ksiOSN4_GXubKG-P2QDaw@mail.gmail.com> <CABkgnnWEx4+o34h70168ZYihs9MFZQ=SNQekNX1gdjq51=-k7g@mail.gmail.com>
Date: Sat, 14 Mar 2015 09:15:14 +1100
Message-ID: <CAH_y2NGOzsgs3SuVcxNdMc76BcdNLUBKuK93aS9j-iJBfevDwA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Jason T. Greene" <jason.greene@redhat.com>, Daniel Stenberg <daniel@haxx.se>, Stefan Eissing <stefan.eissing@greenbytes.de>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e013c6bccab60bf051132d51b"
Received-SPF: permerror client-ip=209.85.215.50; envelope-from=gregw@intalio.com; helo=mail-la0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-2.920, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1YWXrq-0007jI-22 b6cd53939c4e56051395064fbbfb1795
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <http://www.w3.org/mid/CAH_y2NGOzsgs3SuVcxNdMc76BcdNLUBKuK93aS9j-iJBfevDwA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28967
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>

On 14 March 2015 at 05:25, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 13 March 2015 at 06:19, Greg Wilkins <gregw@intalio.com> wrote:
> > Failing the direct PRI approach, it would be far better to try the
> upgrade
> > on an OPTION request before commencing on the big post/put.
>
> I'd always considered it this way:
>
> Read the headers, notice that it is HTTP/2, proceed as though it were
> HTTP/1.1.
> Then, when the response is written, perform a rewrite into HTTP/2.
>


Martin,

there is no obligation for the request to be read before the response is
written and there are many apps that write the response as the request is
read.

Consider an app that performs some kind of streaming translation of the
posted content into the response.  It will be reading chunks of the
HTTP/1.1 response and sending that as frames of HTTP/2 response.
Eventually the stream/connection "window" will be consumed, but a window
update frame will not be able to be sent because the HTTP/1.1 response is
not complete.

I don't see this as impossible, and while it's ugly that the
> specialized code has to exist (for numerous reasons), the specific
> code doesn't have to be ugly if factored well.
>

This is not a issue of uglyness.     It is a question of server consistency
when dealing with the DoS issues and possibility when dealing with the
deadlock issue.

cheers






-- 
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.