Re: WebSocket2

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.


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0006.html

>             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)
https://tools.ietf.org/html/rfc7540

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

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


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0006.html


|                    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

https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt

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

  :schema: http
or
  :schema: https

then it is cachable.


Hypertext Transfer Protocol (HTTP/1.1): Caching
https://tools.ietf.org/html/rfc7234


2.  Overview of Cache Operation
https://tools.ietf.org/html/rfc7234#section-2

|   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


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0008.html

> :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
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
August 12, 2014

but it used also

SETTINGS frame with SETTINGS_WEBSOCKET_CAPABLE


That draft is expired. 
)

Hypertext Transfer Protocol Version 2 (HTTP/2)
https://tools.ietf.org/html/rfc7540


8.1.2.3.  Request Pseudo-Header Fields
https://tools.ietf.org/html/rfc7540#section-8.1.2.3

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

Hopefully

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

then does not apply.



/ Kari Hurtta

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