Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5474218816 for ; Mon, 7 Dec 2015 22:12:27 +0000 (UTC) Received: (qmail 36466 invoked by uid 500); 7 Dec 2015 22:12:26 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 36402 invoked by uid 500); 7 Dec 2015 22:12:26 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 36392 invoked by uid 99); 7 Dec 2015 22:12:26 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Dec 2015 22:12:26 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 34EB9C0FFC for ; Mon, 7 Dec 2015 22:12:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=rowe-clan-net.20150623.gappssmtp.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 9tjwIcPRiz5m for ; Mon, 7 Dec 2015 22:12:15 +0000 (UTC) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 1F08042AD9 for ; Mon, 7 Dec 2015 22:12:15 +0000 (UTC) Received: by igbxm8 with SMTP id xm8so3774128igb.1 for ; Mon, 07 Dec 2015 14:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowe-clan-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X3dYkdAoWMk73ilA0YG/jJ0N54WDhdGtpQiIMCiB0QA=; b=msagao2g6S9YakW/VEV/kvxemkXSMxspg/Y5Jx04AnKeV4a/uCVffMsxnjDEXs0BTG Ghj+44jxPGF+wKTJfbhWN0S67sN5YWgH4V7zOqTA0VfgoGNN2M2KhDFRNh5glSMJmWVh TncwN6ENkcSPgF/s1oAx2BZeiRnfqsLhQ41Elc4SBuds9FiZrzP6K0CktdXPumAqLc58 y8BcgsWIJjX9E0grvhyOFMDL2wq7Z44e9O5AD4fxXlFwpyAioF6OxI3lASFAJ4xvXorY 6OsGzoM1FRCqAGw1DPWmyWe9RB1ObiglKl3IiPYB30Gepn+9yUqjhQkB7Qp6It4Gpp3T cb5w== 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:content-type; bh=X3dYkdAoWMk73ilA0YG/jJ0N54WDhdGtpQiIMCiB0QA=; b=DA0P6J3N7cJupxJbBzj3MostUf6JBbVHyfkkv3pIbryGpd839I4Ceb5dIo5YavnfhK 4xlh7d038XnkOcb6bnZn/+8mPa2uU62FzUqmZOpmT5pFLseyxImi/UD9ONKmfbT9FijS h1Rl+4M1xS+aXqCt5KCv7pzslRIYuMazY/13hBiR9XzOopIjHyMHOK3vb4VZ8+BCmNvT Z3eXG3fQb/HDspcb9drzUni5eNJuPW3hQcYu+NFNfoLbDOUr3qBkaGKsCwnWkG/z9ABh LF7jPcW5gVTlrgWAArGEHWdCwlxAPStJvR8qlHgee7OD0eCiLuRTfaB3v6ioJ2S79AH6 xk2g== X-Gm-Message-State: ALoCoQmutejdva3IrAqwp1s7igIb1ZSeEUxPLrEEaqDJN1Rl6pzivWv6ySoMJDE6i883QkdHG1V3xphediSW+IRGoW050nksyuao6l20YHFTvrVtbAy29uU= MIME-Version: 1.0 X-Received: by 10.50.142.7 with SMTP id rs7mr19422526igb.35.1449526334563; Mon, 07 Dec 2015 14:12:14 -0800 (PST) Received: by 10.107.62.136 with HTTP; Mon, 7 Dec 2015 14:12:14 -0800 (PST) In-Reply-To: <85F6B23C-D866-4F91-ADAD-507C509192FC@greenbytes.de> References: <85F6B23C-D866-4F91-ADAD-507C509192FC@greenbytes.de> Date: Mon, 7 Dec 2015 16:12:14 -0600 Message-ID: Subject: Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls From: William A Rowe Jr To: httpd Content-Type: multipart/alternative; boundary=001a11c2eb5a43c2d5052656260b --001a11c2eb5a43c2d5052656260b Content-Type: text/plain; charset=UTF-8 On Mon, Dec 7, 2015 at 2:39 PM, Stefan Eissing wrote: > There can be no 100 after a 101. After a 101, the downstream speaks the > new protocol, immediately. > Right, and the new protocol is TLS/1.x HTTP/1.1 in the mod_ssl case. What's so confusing? > Am 07.12.2015 um 21:29 schrieb William A Rowe Jr : > > On Mon, Dec 7, 2015 at 2:15 PM, Jacob Champion > wrote: > >> On Dec 7, 2015 8:43 AM, "William A Rowe Jr" wrote: >> > >> > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more >> interesting, it calls out that 101-continue and the request body read >> precedes the 101-switching protocols. Not sure who decided that would be a >> good idea, sigh... >> >> 100-continue can't be after the switch; the new protocol may not have any >> idea what continue semantics are. Similarly, the request body sent is still >> part of an HTTP/1.1 request and should be processed as such. >> >> > but mod_ssl TLS upgrade has these reversed for several good reasons >> including the intent to encrypt the request body if present and simple >> economics of processing. >> >> Did you mean "decrypt the request body"? >> > Yes, my bad... > >> The client needs to send its request body in plaintext since servers are >> free to completely ignore the Upgrade, right? My reading of the specs is >> that an Upgrade request is still a self-contained HTTP/1.1 request, body >> included. >> > No. If the upgrade is rejected, no 101-switching protocols occurs. If > there was no Expect: 100-continue then yes, the body seems part of the > request headers with no way to anticipate how to proceed except plaintext, > but in the case of an Expect: 100-continue, an an interim 101-switching > protocols, a tls handshake, followed by a 100-continue seemed entirely > reasonable. > > It appears we did the wrong thing in the absence of an Expect: > 100-continue, but as a practical matter this seems fairly academic since > RFC7230 codifies a specific sequence that we must adopt, and the instances > of request bodies in upgrade requests seems philosophical. > > > > > --001a11c2eb5a43c2d5052656260b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 7, 2015 at 2:39 PM, Stefan Eissing <stefan.eissing@gree= nbytes.de> wrote:
There can be no 100 after a 101. After a 101, the= downstream speaks the new protocol, immediately.=C2=A0

Right, and the new protocol is TLS/1.x HTTP/1.1 in= the mod_ssl case.=C2=A0 What's
so confusing?

<= /div>
=C2=A0
Am 07.12.2015 um 21:29 schrieb William A Rowe Jr &l= t;wrowe@rowe-clan.= net>:

<= div class=3D"gmail_extra">
On Mon, Dec 7, 2015 at= 2:15 PM, Jacob Champion <champion.p@gmail.com> wrote:

On Dec 7, 2015 8:43 AM= , "William A Rowe Jr" <wrowe@rowe-clan.net> wrote:
>
> https://tools.ietf.org/html/rfc7230#section-6.7 makes things mo= re interesting, it calls out that 101-continue and the request body read pr= ecedes the 101-switching protocols.=C2=A0 Not sure who decided that would b= e a good idea, sigh...

100-continue can't be after the switch; the new p= rotocol may not have any idea what continue semantics are. Similarly, the r= equest body sent is still part of an HTTP/1.1 request and should be process= ed as such.

> but mod_ssl TLS upgrade has these reversed for several = good reasons including the intent to encrypt the request body if present an= d simple economics of processing.

Did you mean "decrypt the request body"?

Yes, my bad...=C2=A0
The client needs to send its request body in plaintext sin= ce servers are free to completely ignore the Upgrade, right? My reading of = the specs is that an Upgrade request is still a self-contained HTTP/1.1 req= uest, body included.

No.=C2=A0 If the upgrade is rejec= ted, no 101-switching protocols occurs.=C2=A0 If there was no Expect: 100-c= ontinue then yes, the body seems part of the request headers with no way to= anticipate how to proceed except plaintext, but in the case of an Expect: = 100-continue, an an interim 101-switching protocols, a tls handshake, follo= wed by a 100-continue seemed entirely reasonable.

<= div>It appears we did the wrong thing in the absence of an Expect: 100-cont= inue, but as a practical matter this seems fairly academic since RFC7230 co= difies a specific sequence that we must adopt, and the instances of request= bodies in upgrade requests seems philosophical.

<= br>



--001a11c2eb5a43c2d5052656260b--