Subject: Draft HTTPbis Agenda For Seoul IETF 97

From: Patrick McManus <[email-masked]>
Date: Mon, 17 Oct 2016 21:22:46 -0400

Hi Folks,

Mark and I have started to put together an agenda for our meeting in Korea
- it is subject to change as necessary, so please shout out if you have
input or something you would like to raise.

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf97/agenda.md

The preliminary schedule has our group scheduled for 2 hours on Tuesday
afternoon, and 1 hour on Thursday morning. Remember, that's preliminary.

-Patrick

---

From: Van Catha <[email-masked]>
Date: Wed, 19 Oct 2016 10:03:18 -0400

I am particularly interest in the future of 2 way binary streaming.  So the
topics of WebSocket, Streams API and other related. I have even put forward
a draft related to the WebSocket part.
https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Oct 2016 10:34:21 -0400

> https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/

Thanks Van - I've noted that on the agenda as related work so people can
familiarize themselves with it.

-Patrick

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 19 Oct 2016 19:50:45 +0300

> https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/

Some quick review comments:

- The handshake seems to negotiate compression and then the frames
  contain compression method indicator. Are there really multiple
  compression methods available on per-frame basis, or should the
  compression just be 1 bit (compressed or not)?
- The abbrevations in frame diagram are bit difficult to understand
  (have those be expanded in above text?).
- Somebody needs to try what this does against many HTTP/2 origins
  that don't support WebSockets2 and against intermediaries with
  custom server that actually supports it. Just to see what the
  heck happens (if it is nasty, one might need to use SETTINGS to
  signal support, either for WebSockets directly or for some sort
  of strict scheme).
- What is "valid UTF-8" exactly? E.g. does it contain encodings for
  Unicode noncharacters?

-Ilari

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Oct 2016 09:48:45 +0900

Hi,

>   signal support, either for WebSockets directly or for some sort

That's a good point.

In case of H2O, all schemes are handling equally at the protocol
layer. In other words, whatever the :scheme is, the server is designed
to wait for a request, and then send response.

My understanding is that the HTTP/2 specification is written in mind
to allow such implementations, and that it would be a violation of
HTTP/2 to introduce different interactions by using :scheme as an
indicator. For example, transition of the stream states described in
section 5.1 is not restricted to specific schemes.

So if we are to start using the HTTP/2 framing layer to transmit
websocket or other bi-directional communication, I think we should
require negotiation using SETTINGS frame. Also, it might be beneficial
to use a frame type other than DATA to convey bi-directional
information to avoid potential issues (since the transition of the
stream states are mostly related to how DATA frames are handled).

-- 
Kazuho Oku

---

From: Tom Bergan <[email-masked]>
Date: Wed, 19 Oct 2016 18:31:26 -0700

> stream states are mostly related to how DATA frames are handled).

Ignoring the practical issues for a moment (which are obviously important),
which part of the H2 spec forbids bidirectional communication as desired by
WebSockets2? The stream state diagram in section 5.1 says that a stream
transitions from "idle" to "open" when the client/server sends/receives a
HEADERS frame (with CONTINUATIONs). A stream doesn't transition to a
"closed" state until a peer sends an ENDS_STREAM flag. Section 5.1 says: "A
stream in the 'open' state may be used by both peers to send frames of any
type." This seems to explicitly allow bidirectional communication with DATA
frames as desired by WebSockets2. Further, WebSockets2's bidirectional
communication looks very similar to bidirectional streaming in gRPC:
http://www.grpc.io/docs/guides/concepts.html#bidirectional-streaming-rpc
http://www.grpc.io/docs/guides/wire.html

In practice, I could see that some servers will try to consume the entire
request before returning any kind of response, and this definitely might
interact poorly with WebSockets2.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Oct 2016 12:46:04 +0900

> http://www.grpc.io/docs/guides/wire.html

Thank you for your comment.

I agree that a stream remains in open state until a frame with an
END_STREAM flag is sent by either of the two communication bodies. So
HTTP/2 as a spec. does not forbid using DATA frames for bidirectional
communication.

> interact poorly with WebSockets2.

Yes.

This could be the case for any HTTP/2 gateway that translates incoming
requests to HTTP/1, that does not reject unknown schemes. And whether
such gateway needs to reject schemes that do not match to the
request-response model of HTTP seems to be vague in reading RFC 7540.
Section 8.1.2.3 states that:

      ":scheme" is not restricted to "http" and "https" schemed URIs.  A
      proxy or gateway can translate requests for non-HTTP schemes,
      enabling the use of HTTP to interact with non-HTTP services.

My interpretation of this paragraph would be that it is permitted for
an HTTP/2 intermediary to transmit requests with schemes other than
"http" or "https", expecting that an upstream server would process the
request according to the scheme, considering the fact that (per my
understanding) such action is permitted in HTTP/1.1.

-- 
Kazuho Oku

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 20 Oct 2016 10:18:47 +0300 (EEST)

Yes.

There is one exception however. When there is no :scheme and :method is
CONNECT.

But all :scheme:s are equal.  HTTP is used to connect to proxy
and that is HTTP request/response model. Proxy then translate
request to protocol indicated by :scheme.

> require negotiation using SETTINGS frame.

Yes, I suggested that also.  (There was many posts
about SETTINGS_WEBSOCKET_CAPABLE).

/ Kari Hurtta

https://tools.ietf.org/html/draft-svirid-websocket2-over-http2-00#appendix-A

|   The author wishes to thank Kari hurtta for contributing the
|   handshake.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 20 Oct 2016 16:27:20 +0900

Hi Patrick,

Could you please also add https://tools.ietf.org/html/draft-yoshino-wish-00
to the "Messaging/Websockets for H2" part?

Thanks

Takeshi

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 20 Oct 2016 12:33:55 +0300 (EEST)

> understanding) such action is permitted in HTTP/1.1.

Yes. HTTP/2 explicitly uses HTTP/1.1 semantic. 

8.  HTTP Message Exchanges
https://tools.ietf.org/html/rfc7540#section-8

|   Thus, the specification and requirements of HTTP/1.1 Semantics and
|   Content [RFC7231], Conditional Requests [RFC7232], Range Requests
|   [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
|   applicable to HTTP/2.  Selected portions of HTTP/1.1 Message Syntax
|   and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
|   also applicable in HTTP/2, but the expression of those semantics for
|   this protocol are defined in the sections below.

3.1.  Client Handshake Request
https://tools.ietf.org/html/draft-svirid-websocket2-over-http2-00#section-3.1

| 3.1.  Client Handshake Request
| 
|    The client MUST use the :method GET.
| 
|    The client MUST send a sec-ws2-version header that MUST specify the
|    websocket2 version being used.
| 
|    The client MAY send a sec-ws2-compression header that advertises the
|    compression methods the client supports.  Valid key value pairs
|   include:

↡

| The client MUST NOT set the END_STREAM flag when sending the headers.

Note however that this apply:

4.3.1.  GET
https://tools.ietf.org/html/rfc7231#section-4.3.1

|   A payload within a GET request message has no defined semantics;
|   sending a payload body on a GET request might cause some existing
|   implementations to reject the request.
|
|   The response to a GET request is cacheable; a cache MAY use it to
|   satisfy subsequent GET and HEAD requests unless otherwise indicated
|   by the Cache-Control header field (Section 5.2 of [RFC7234]).

Changing of scheme does not change semantic of methods.

2.  Resources
https://tools.ietf.org/html/rfc7231#section-2

|   One design goal of HTTP is to separate resource identification from
|   request semantics, which is made possible by vesting the request
|   semantics in the request method (Section 4) and a few
|   request-modifying header fields (Section 5).  If there is a conflict
|   between the method semantics and any semantic implied by the URI
|   itself, as described in Section 4.2.1, the method semantics take
|   precedence.

( scheme is part of URI )

2.7.  Uniform Resource Identifiers
https://tools.ietf.org/html/rfc7230#section-2.7

|   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
|   HTTP as the means for identifying resources (Section 2 of [RFC7231]).
|   URI references are used to target requests, indicate redirects, and
|   define relationships.

/ Kari Hurtta

---

From: Patrick McManus <[email-masked]>
Date: Thu, 20 Oct 2016 09:19:52 -0400

yes - thank you for the draft.

On Thu, Oct 20, 2016 at 3:27 AM, Takeshi Yoshino <[email-masked]>
wrote:

> Hi Patrick,
>
> Could you please also add https://tools.ietf.org/html/
> draft-yoshino-wish-00 to the "Messaging/Websockets for H2" part?
>
> Thanks
>
> Takeshi
>

---

From: Van Catha <[email-masked]>
Date: Thu, 20 Oct 2016 15:17:49 -0400

>  compression just be 1 bit (compressed or not)?

The use case for this is that when using lz4, small frames under 20 octets
in size often end up being larger after compression.
This way the server can have more control of what it sends to client.

The reason for having different types of compression is to support a broad
range of data being transmitted. especially for all the
new custom protocol we have popping up.

>  (have those be expanded in above text?).

I agree on this. It is hard to draw up the frames and represent everything.
But rough idea when parsing is (everything is unsigned):

InnerFrame = case (Length = recv(1)):
  255:
    Length = recv(4)
  254:
    Length = recv(2)
  finally:
    recv(Length)

FrameHeader = InnerFrame[0]
FrameBody = InnerFrame[1,]
... continue

At first I had static sizes instead of the variable size, but the static
sizes produce extra bytes on the wire which can be reduces by introducing
some complexity. For example before a 100 octet sized frame length would
take 4 octets on the wire, now it just takes 1.

>  signal support, either for WebSockets directly or for some sort

I think settings maybe the way to go at this point.  It seems to be quite
well received.

It would be scanning over the string and validating every code point.    The
only reason this is included is to be backward compatible with WebSocket.

Ideally I just wanted to have binary frames, then when you receive them you
can
cast them to strings.

> Changing of scheme does not change semantic of methods.

It seems that sending a Cache-Control header to indicate no caching would
work then?

I thought that a middlebox cannot cache ANYTHING unless the response
contains headers to allow caching.
It seems the opposite, anything can be cached unless strictly told not to.

The problem with CONNECT method is it seems to be used now for establishing
tunneling between middleboxes.

Introducing a custom method like WS2 also seems a little out of place.  But
a custom method method like
UPGRADE or something to indicate something is going on could work.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 20 Oct 2016 22:41:03 +0300 (EEST)

Van Catha <[email-masked]>: (Thu Oct 20 22:17:49 2016)
> It seems that sending a Cache-Control header to indicate no caching would

Semantic still does not match.

| 4.3.1.  GET
| 
|    The GET method requests transfer of a current selected representation
|    for the target resource.  

RFC 6455 also used GET -method, but it was changing protocol because of Upgrade.

1.3.  Opening Handshake
https://tools.ietf.org/html/rfc6455#section-1.3

|        GET /chat HTTP/1.1
|        Host: server.example.com
|        Upgrade: websocket
|        Connection: Upgrade

> It seems the opposite, anything can be cached unless strictly told not to.

4.2.3.  Cacheable Methods
https://tools.ietf.org/html/rfc7231#section-4.2.3

|   Request methods can be defined as "cacheable" to indicate that
|   responses to them are allowed to be stored for future reuse; for
|   specific requirements see [RFC7234].  In general, safe methods that
|   do not depend on a current or authoritative response are defined as
|   cacheable; this specification defines GET, HEAD, and POST as
|   cacheable, although the overwhelming majority of cache
|   implementations only support GET and HEAD.

/ Kari Hurtta

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 1 Nov 2016 10:47:48 +0900

Hi,

Thank you for arranging the meeting.

I know it's very late, but I would appreciate it if we could discuss
https://tools.ietf.org/html/draft-kazuho-early-hints-status-code-00 as
well.

Thank you in advance.

2016-10-18 10:22 GMT+09:00 Patrick McManus <[email-masked]>:
> Hi Folks,
>
> Mark and I have started to put together an agenda for our meeting in Korea -
> it is subject to change as necessary, so please shout out if you have input
> or something you would like to raise.
>

-- 
Kazuho Oku