Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Fri, 10 November 2017 05:50 UTC

Return-Path: <khurtta@welho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D912EAF9 for <hybi@ietfa.amsl.com>; Thu, 9 Nov 2017 21:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no
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 fHeIqswq-rqh for <hybi@ietfa.amsl.com>; Thu, 9 Nov 2017 21:50:04 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E87112EAB6 for <hybi@ietf.org>; Thu, 9 Nov 2017 21:50:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D237B5DE4C; Fri, 10 Nov 2017 07:50:01 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id seicjA-C1-UB; Fri, 10 Nov 2017 07:49:59 +0200 (EET)
Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id D6E1E2315; Fri, 10 Nov 2017 07:49:51 +0200 (EET)
In-Reply-To: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com>
References: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com>
To: Wenbo Zhu <wenboz@google.com>, Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 10 Nov 2017 07:49:57 +0200 (EET)
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha46+]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171110055001.D237B5DE4C@welho-filter3.welho.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/F6XUsaODA3A0lD_BNa_OOMXxLyA>
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Nov 2017 05:50:07 -0000

> 1. as I understand, RFC7540 only states that early 2xx responses are
> allowed, i.e. when response headers are generated, any pending request body
> becomes insignificant. Therefore the explicit tunneling mechanism is
> necessary to signal to proxies/frameworks that a full-duplex byte-stream is
> being tunneled as a http/2 stream.


Yes, full-duplex byte-stream is quote different from http request-response model.


8.1.  HTTP Request/Response Exchange
https://tools.ietf.org/html/rfc7540#section-8.1


states

-------------

   An HTTP request/response exchange fully consumes a single stream.  A
   request starts with the HEADERS frame that puts the stream into an
   "open" state.  The request ends with a frame bearing END_STREAM,
   which causes the stream to become "half-closed (local)" for the
   client and "half-closed (remote)" for the server.  A response starts
   with a HEADERS frame and ends with a frame bearing END_STREAM, which
   places the stream in the "closed" state.

   An HTTP response is complete after the server sends -- or the client
   receives -- a frame with the END_STREAM flag set (including any
   CONTINUATION frames needed to complete a header block).  A server can
   send a complete response prior to the client sending an entire
   request if the response does not depend on any portion of the request
   that has not been sent and received.  When this is true, a server MAY
   request that the client abort transmission of a request without error
   by sending a RST_STREAM with an error code of NO_ERROR after sending
   a complete response (i.e., a frame with the END_STREAM flag).
   Clients MUST NOT discard responses as a result of receiving such a
   RST_STREAM, though clients can always discard responses at their
   discretion for other reasons.

--------------

/ Kari Hurtta