- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 13 Nov 2017 09:03:27 +0800
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Patrick, Thank you for the updates. -02 looks very good to me; let me happily retract my comment to the previous draft suggesting that we should allow use of any method and use 101 as a signal that the protocol has switched. The point I had missed is that END_STREAM is used as a signal to indicate the end of the request under all methods except CONNECT. OTOH, in WebSockets (or in any other protocol upgraded from HTTP), we would want to use the stream (without sending END_STREAM) to transfer the bidirectional communication. There are three possible solutions: a) use CONNECT (or define a new method that has the same characteristics as CONNECT; i.e. END_HEADERS marks end of the request), b) define a new mechanism for detecting the boundary between end of the HTTP request and the beginning of the payload of the upgraded bi-directional stream, c) use a new pseudo-header that instructs the server to consider END_HEADERS as the end of the request for any given method. Considering the fact that the only protocol upgraded from HTTP that we care now is WebSocket which only uses GET, I now agree that option a is a logical solution. The remaining question is if we might want to convey HTTP request body in a future protocol that upgrades from a HTTP/2 stream (or a QUIC-HTTP stream). We should choose option b if we think that it is highly probable to see proposals for such protocols. But I am not sure if that is the case, hence my support for option a (i.e. reuse CONNECT method). It’s a pity that you would need to rewrite the method in a reverse proxy that forwards HTTP/2 to ws-h1. But I think I can cope with that. 2017-11-13 6:53 GMT+08:00 Patrick McManus <mcmanus@ducksong.com>: > fyi > ---------- Forwarded message ---------- > From: <internet-drafts@ietf.org> > Date: Mon, Nov 13, 2017 at 6:52 AM > Subject: New Version Notification for > draft-mcmanus-httpbis-h2-websockets-02.txt > To: Patrick McManus <mcmanus@ducksong.com> > > > > A new version of I-D, draft-mcmanus-httpbis-h2-websockets-02.txt > has been successfully submitted by Patrick McManus and posted to the > IETF repository. > > Name: draft-mcmanus-httpbis-h2-websockets > Revision: 02 > Title: Bootstrapping WebSockets with HTTP/2 > Document date: 2017-11-11 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-02.txt > Status: > https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/ > Htmlized: > https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-mcmanus-httpbis-h2-websockets-02 > > Abstract: > This document defines a mechanism for running the WebSocket Protocol > [RFC6455] over a single stream of an HTTP/2 connection. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- Kazuho Oku
Received on Monday, 13 November 2017 01:04:21 UTC