tunnel | Re: WebSocket2

Alex Rousskov <rousskov@measurement-factory.com>: (Tue Oct  4 00:52:08 2016)
> >From the real world compatibility point of view, if WebSocket2 are going
> to use TCP port(s) commonly used for HTTP and HTTPS traffic, it would be
> great if an HTTP proxy (any HTTP version) can easily identify and tunnel
> that WebSocket2 traffic without implementing WebSocket2.

Is this

RFC 7639: The ALPN HTTP Header Field
> Thank you,
> Alex.

Except that here is no ALPN  token for websocket.

Application-Layer Protocol Negotiation (ALPN) Protocol IDs

Protocol 	Identification Sequence 				Reference
HTTP/1.1 	0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") 	[RFC7230]
SPDY/1 		0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1") 		[http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1]
SPDY/2 		0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2") 		[http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2]
SPDY/3 		0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") 		[http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3]
Traversal Using Relays around NAT (TURN) 	0x73 0x74 0x75 0x6E 0x2E 0x74 0x75 0x72 0x6E ("stun.turn") 	[RFC7443]
NAT discovery using Session Traversal Utilities for NAT (STUN) 	0x73 0x74 0x75 0x6E 0x2E 0x6e 0x61 0x74 0x2d 0x64 0x69 0x73 0x63 0x6f 0x76 0x65 0x72 0x79 ("stun.nat-discovery") 	[RFC7443]
HTTP/2 over TLS 	0x68 0x32 ("h2") 				[RFC7540]
HTTP/2 over TCP 	0x68 0x32 0x63 ("h2c") 				[1][RFC7540]
WebRTC Media and Data 	0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") 	[RFC-ietf-rtcweb-alpn-04]
Confidential WebRTC Media and Data 	0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 ("c-webrtc") 	[RFC-ietf-rtcweb-alpn-04]
FTP 		0x66 0x74 0x70 ("ftp") 					[RFC959][RFC4217]

/ Kari Hurtta

Received on Tuesday, 4 October 2016 17:27:19 UTC