WebSocket协议RFC 6455：浏览器与服务器双向通信的基石

需积分: 9 121 浏览量更新于2024-07-15 收藏 235KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

RFC 6455

The WebSocket Protocol December 2011

1.9. Subprotocols Using the WebSocket Protocol

_This section is non-normative._

The client can request that the server use a specific subprotocol by

including the |Sec-WebSocket-Protocol| field in its handshake. If it

is specified, the server needs to include the same field and one of

the selected subprotocol values in its response for the connection to

be established.

These subprotocol names should be registered as per Section 11.5. To

avoid potential collisions, it is recommended to use names that

contain the ASCII version of the domain name of the subprotocol’s

originator. For example, if Example Corporation were to create a

Chat subprotocol to be implemented by many servers around the Web,

they could name it "chat.example.com". If the Example Organization

called their competing subprotocol "chat.example.org", then the two

subprotocols could be implemented by servers simultaneously, with the

server dynamically selecting which subprotocol to use based on the

value sent by the client.

Subprotocols can be versioned in backward-incompatible ways by

changing the subprotocol name, e.g., going from

"bookings.example.net" to "v2.bookings.example.net". These

subprotocols would be considered completely separate by WebSocket

clients. Backward-compatible versioning can be implemented by

reusing the same subprotocol string but carefully designing the

actual subprotocol to support this kind of extensibility.

2. Conformance Requirements

All diagrams, examples, and notes in this specification are non-

normative, as are all sections explicitly marked non-normative.

Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [

RFC2119].

Requirements phrased in the imperative as part of algorithms (such as

"strip any leading space characters" or "return false and abort these

steps") are to be interpreted with the meaning of the key word

("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.

Fette & Melnikov Standards Track [Page 12]

RFC 6455

The WebSocket Protocol December 2011

Conformance requirements phrased as algorithms or specific steps MAY

be implemented in any manner, so long as the end result is

equivalent. (In particular, the algorithms defined in this

specification are intended to be easy to follow and not intended to

be performant.)

2.1. Terminology and Other Conventions

_ASCII_ shall mean the character-encoding scheme defined in

[

ANSI.X3-4.1986].

This document makes reference to UTF-8 values and uses UTF-8

notational formats as defined in STD 63 [

RFC3629].

Key terms such as named algorithms or definitions are indicated like

_this_.

Names of header fields or variables are indicated like |this|.

Variable values are indicated like /this/.

This document references the procedure to _Fail the WebSocket

Connection_. This procedure is defined in Section 7.1.7.

_Converting a string to ASCII lowercase_ means replacing all

characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER

A to LATIN CAPITAL LETTER Z) with the corresponding characters in the

range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL

LETTER Z).

Comparing two strings in an _ASCII case-insensitive_ manner means

comparing them exactly, code point for code point, except that the

characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER

A to LATIN CAPITAL LETTER Z) and the corresponding characters in the

range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL

LETTER Z) are considered to also match.

The term "URI" is used in this document as defined in [

RFC3986].

When an implementation is required to _send_ data as part of the

WebSocket Protocol, the implementation MAY delay the actual

transmission arbitrarily, e.g., buffering data so as to send fewer IP

packets.

Note that this document uses both [

RFC5234] and [RFC2616] variants of

ABNF in different sections.

Fette & Melnikov Standards Track [Page 13]

RFC 6455

The WebSocket Protocol December 2011

Clients running in controlled environments, e.g., browsers on mobile

handsets tied to specific carriers, MAY offload the management of the

connection to another agent on the network. In such a situation, the

client for the purposes of this specification is considered to

include both the handset software and any such agents.

When the client is to _Establish a WebSocket Connection_ given a set

of (/host/, /port/, /resource name/, and /secure/ flag), along with a

list of /protocols/ and /extensions/ to be used, and an /origin/ in

the case of web browsers, it MUST open a connection, send an opening

handshake, and read the server’s handshake in response. The exact

requirements of how the connection should be opened, what should be

sent in the opening handshake, and how the server’s response should

be interpreted are as follows in this section. In the following

text, we will use terms from

Section 3, such as "/host/" and

"/secure/ flag" as defined in that section.

1. The components of the WebSocket URI passed into this algorithm

(/host/, /port/, /resource name/, and /secure/ flag) MUST be

valid according to the specification of WebSocket URIs specified

Section 3. If any of the components are invalid, the client

MUST _Fail the WebSocket Connection_ and abort these steps.

2. If the client already has a WebSocket connection to the remote

host (IP address) identified by /host/ and port /port/ pair, even

if the remote host is known by another name, the client MUST wait

until that connection has been established or for that connection

to have failed. There MUST be no more than one connection in a

CONNECTING state. If multiple connections to the same IP address

are attempted simultaneously, the client MUST serialize them so

that there is no more than one connection at a time running

through the following steps.

If the client cannot determine the IP address of the remote host

(for example, because all communication is being done through a

proxy server that performs DNS queries itself), then the client

MUST assume for the purposes of this step that each host name

refers to a distinct remote host, and instead the client SHOULD

limit the total number of simultaneous pending connections to a

reasonably low number (e.g., the client might allow simultaneous

pending connections to a.example.com and b.example.com, but if

thirty simultaneous connections to a single host are requested,

that may not be allowed). For example, in a web browser context,

the client needs to consider the number of tabs the user has open

in setting a limit to the number of simultaneous pending

connections.

Fette & Melnikov Standards Track [Page 15]

剩余70页未读，继续阅读

mikeyu9

粉丝: 1
资源: 26

WebSocket协议RFC 6455：浏览器与服务器双向通信的基石

The WebSocket Protocol RFC

netty websocket sec-websocket-protocol

laya的websocket添加Sec-WebSocket-Protocol

js Socket怎样添加Sec-WebSocket-Protocol头

websocket header

c++写的libhv中WebSocketService添加Sec-WebSocket-Protocol

websocket连接WebSocket on-close event

failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

js的Socket添加Sec-WebSocket-Protocol

netty-websocket-spring-boot-starter

tio-websocket-spring-boot-starter，这个jar包哪里能下载

tio-websocket-spring-boot-starter 的简单使用

使用tio-websocket-spring-boot-starter组件实现客户端消息的接收和发送

sec-websocket-protocol如何修改

netty-websocket-spring-boot-starter使用案例

websocket ready

js websocket headers

在SpringBoot项目中，用java实现websocket服务端，客户端发送Sec-WebSocket-Key后，服务端返回Sec-WebSocket-Accept

Sec-WebSocket-accept

javax.websocket-api-1.0.jar.zip

最新资源