W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: WebSocket2

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Sun, 2 Oct 2016 10:13:07 +0300 (EEST)
Message-Id: <201610020713.u927D7q1001934@shell.siilo.fmi.fi>
To: Van Catha <vans554@gmail.com>
CC: Kari hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
Van Catha <vans554@gmail.com>: (Sun Oct  2 00:21:19 2016)
> I just do not see the necessity.  We have custom headers in HTTP/1.1 for a
> long time and no one has had a problem with it.

My reason was:

| There [you] start using of HTTP/2 DATA
| frames. These usage however differ
| very much from usage of http -request
| and response.

Your use is not that send all request body
on DATA frames and then send response body
on DATA frames to different direction.


>             HTTP/2 was designed from the
>  very beginning to not support 2 way streaming like websocket provides
>  currently for HTTP/1.1.  

Yes, that is reason why I suspect that you need negotate this.

Hypertext Transfer Protocol Version 2 (HTTP/2)

8.1.  HTTP Request/Response Exchange

|   A client sends an HTTP request on a new stream, using a previously
|   unused stream identifier (Section 5.1.1).  A server sends an HTTP
|   response on the same stream as the request.
|   An HTTP message (request or response) consists of:
|   1.  for a response only, zero or more HEADERS frames (each followed
|       by zero or more CONTINUATION frames) containing the message
|       headers of informational (1xx) HTTP responses (see [RFC7230],
|       Section 3.2 and [RFC7231], Section 6.2),
|   2.  one HEADERS frame (followed by zero or more CONTINUATION frames)
|       containing the message headers (see [RFC7230], Section 3.2),
|   3.  zero or more DATA frames containing the payload body (see
|       [RFC7230], Section 3.3), and
|   4.  optionally, one HEADERS frame, followed by zero or more
|       CONTINUATION frames containing the trailer-part, if present (see
|       [RFC7230], Section 4.1.2).
|   The last frame in the sequence bears an END_STREAM flag, noting that
|   a HEADERS frame bearing the END_STREAM flag can be followed by
|   CONTINUATION frames that carry any remaining portions of the header
|   block.

and so on

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

First question: Is there http/2 proxies at all?


|                    Again if the proxy is
| "smart" and decides to cache the response (which did not specify any
| headers related to caching) its the proxies fault. 

I found at least on there

  :method: GET


I also note that required :schema was missing, If it was

  :schema: http
  :schema: https

then it is cachable.

Hypertext Transfer Protocol (HTTP/1.1): Caching

2.  Overview of Cache Operation

|   Each cache entry consists of a cache key and one or more HTTP
|   responses corresponding to prior requests that used the same key.
|   The most common form of cache entry is a successful result of a
|   retrieval request: i.e., a 200 (OK) response to a GET request, which
|   contains a representation of the resource identified by the request
|   target (Section 4.3.1 of [RFC7231]).  However, it is also possible to
|   cache permanent redirects, negative results (e.g., 404 (Not Found)),
|   incomplete results (e.g., 206 (Partial Content)), and responses to
|   methods other than GET if the method's definition allows such caching
|   and defines something suitable for use as a cache key


> :scheme is perfect! Wow.  If we could pass ws/wss for example as the scheme
> that
> fits perfectly. Looking at https://tools.ietf.org/html/rfc3986#section-3.1
> the spec for schemes
> it seems ws and wss are perfectly valid schemes to use and are registered;
> http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.

Using :schema other than http or https, may be negotation what you need
with proxy.

> Where is the problem in HTTP/2 that would disallow schemes different from
> http and https, I do not see
> anything related to this?

My viewpoint is just opposite. ( I suppose that you do not want
negotiate with proxy. )

You need negotiate your usage with next hop. Hopefully using your scheme
is recognised as negotation by proxies.

( That idea of using :scheme ws or wss was also on

WebSocket over HTTP/2
August 12, 2014

but it used also


That draft is expired. 

Hypertext Transfer Protocol Version 2 (HTTP/2)
https://tools.ietf.org/html/rfc7540  Request Pseudo-Header Fields

|   o  The ":scheme" pseudo-header field includes the scheme portion of
|      the target URI ([RFC3986], Section 3.1).
|      ":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.

Other schemas are allowed.


8.  HTTP Message Exchanges

then does not apply.

/ Kari Hurtta
Received on Sunday, 2 October 2016 07:13:41 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 October 2016 07:13:42 UTC