- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 4 Oct 2016 18:20:06 +0300 (EEST)
- To: Takeshi Yoshino <tyoshino@google.com>
- CC: Van Catha <vans554@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Takeshi Yoshino <tyoshino@google.com>: (Tue Oct 4 14:12:25 2016)
> Hi Van, Kari,
>
> On Tue, Oct 4, 2016 at 1:39 AM, Van Catha <vans554@gmail.com> wrote:
>
> <snip>
>
>
> > Kari Hurtta
> >
> > > Well, I think the following would work and avoid SETTINGS:
> > >
> >
>
> Yutaka's proposal required the SETTINGS_WEBSOCKET_CAPABLE SETTINGS
> parameter because we planned to use special framing (use of HTTP2 framing
> level features not used for HTTP1.1/h2 layering). We wanted allow endpoints
> to make sure that the h2 intermediaries between them are able to forward
> WS/HTTP2's special framing correctly.
>
> So, for the current proposal by Van where only the DATA frame is used as
> well as HTTP1.1/h2 layering, it's unnecessary.
I contemplated SETTINGS as:
∙ SETTINGS frame with SETTINGS_WEBSOCKET_CAPABLE = 1
from HTTP/2 server ⇒ HTTP/1 client direction
∘ Promises that HTTP/2 server checks ":scheme"
(and specially "wss" and "ws")
∘ Acknowledges that DATA frames for
":scheme" = "wss" and "ws" are handled
as bidirectional traffic (similar than
":method" = "CONNECT").
In other words these DATA drames do
NOT form HTTP request body from client
and DATA drames do not form
HTTP response body from server
(on cases ":scheme" = "wss" and "ws").
∘ SETTINGS_WEBSOCKET_CAPABLE = 1 does
not promise that HTTP/2 server
accepts ":scheme" = "wss" or "ws".
(※)
∙ Promise of HTTP/1 client (⇒ HTTP/2 server)
is implied with ":scheme" = "wss" or "ws".
> > > -> :method ws2
> > > -> :scheme wss
> > > -> :authority foo.example
> > > -> :path /bar
> > > -> <optional extra parameters, e.g. compression support>
> > > <- :status 200
> > > <- sec-ws2-ack 1
> > > <- <optional negotiated extras>
> >
> >
> :scheme is needed, yes.
>
> Not sure about need for "sec-ws2-ack". For WebSocket/TCP, we employed the
> Sec-WebSocket-Key/Accept challenge/response in order to prevent the
> WebSocket protocol from being abused for cross protocol attacks e.g. SMTP.
> If all the intermediaries and servers correctly investigate the :scheme
> header and don't get confused, "sec-ws2-ack" is unnecessary. Regarding
> ws/h2-RFC6455 bridging, a correctly implemented intermediary facing ws/h2
> capable node and ws/h2 non-capable node would just perform RFC 6455
> handshake as Kari suggested. So, no problem.
Ilari Liusvaara suggested sec-ws2-ack for check that
":scheme" is not ignored (if I remember correctly).
/ Kari Hurtta
(※) Yes, on my network picture there is
many HTTP/2 servers and clients:
+---------------------------+
| Web browser or other |
| WebSockect client |
+---------------------------+ [ HTTP/2 client ]
⇓
⇓
+---------------------------+ [ HTTP/2 server ]
| forward proxy configure | ( client uses CONNECT
| on web blowser | tunnel if encypted scheme )
+---------------------------+ [ HTTP/2 client ]
⇓
⇓
+---------------------------+ [ HTTP/2 client ]
| reverse proxy for | ( may include TLS offloading,
| :authority | if encryption is used )
+---------------------------+ [ HTTP/2 client ]
⇓
⇓
+---------------------------+ [ HTTP/2 server ]
| origin server |
| |
+---------------------------+
SETTINGS frame is for one hop between
HTTP/2 server and HTTP/2 client.
Received on Tuesday, 4 October 2016 15:20:49 UTC