目錄 搜尋
Guides Access control CORS Authentication Browser detection using the user agent Caching Caching FAQ Compression Conditional requests Connection management in HTTP 1.x Content negotiation Content negotiation: List of default Accept values Cookies CSP Messages Overview Protocol upgrade mechanism Proxy servers and tunneling Proxy servers and tunneling: Proxy Auto-Configuration (PAC) file Public Key Pinning Range requests Redirections Resources and specifications Resources and URIs Response codes Server-Side Access Control Session Guides: Basics Basics of HTTP Choosing between www and non-www URLs Data URIs Evolution of HTTP Identifying resources on the Web MIME Types MIME types: Complete list of MIME types CSP Content-Security-Policy Content-Security-Policy-Report-Only CSP: base-uri CSP: block-all-mixed-content CSP: child-src CSP: connect-src CSP: default-src CSP: font-src CSP: form-action CSP: frame-ancestors CSP: frame-src CSP: img-src CSP: manifest-src CSP: media-src CSP: object-src CSP: plugin-types CSP: referrer CSP: report-uri CSP: require-sri-for CSP: sandbox CSP: script-src CSP: style-src CSP: upgrade-insecure-requests CSP: worker-src Headers Accept Accept-Charset Accept-Encoding Accept-Language Accept-Ranges Access-Control-Allow-Credentials Access-Control-Allow-Headers Access-Control-Allow-Methods Access-Control-Allow-Origin Access-Control-Expose-Headers Access-Control-Max-Age Access-Control-Request-Headers Access-Control-Request-Method Age Allow Authorization Cache-Control Connection Content-Disposition Content-Encoding Content-Language Content-Length Content-Location Content-Range Content-Type Cookie Cookie2 Date DNT ETag Expect Expires Forwarded From Headers Host If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since Keep-Alive Large-Allocation Last-Modified Location Origin Pragma Proxy-Authenticate Proxy-Authorization Public-Key-Pins Public-Key-Pins-Report-Only Range Referer Referrer-Policy Retry-After Server Set-Cookie Set-Cookie2 SourceMap Strict-Transport-Security TE Tk Trailer Transfer-Encoding Upgrade-Insecure-Requests User-Agent User-Agent: Firefox Vary Via Warning WWW-Authenticate X-Content-Type-Options X-DNS-Prefetch-Control X-Forwarded-For X-Forwarded-Host X-Forwarded-Proto X-Frame-Options X-XSS-Protection Methods CONNECT DELETE GET HEAD Methods OPTIONS PATCH POST PUT Status 100 Continue 101 Switching Protocols 200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modified 307 Temporary Redirect 308 Permanent Redirect 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Payload Too Large 414 URI Too Long 415 Unsupported Media Type 416 Range Not Satisfiable 417 Expectation Failed 426 Upgrade Required 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported 511 Network Authentication Required Status
文字

在HTTP协议提供了一个特殊机制,使已建立的连接升级到一个新的,不兼容,协议。本指南介绍了它的工作原理,并提供了其使用场景的示例。

此机制始终由客户端启动(有一个例外:服务器可能需要升级到TLS),并且服务器可能接受或拒绝切换到新协议。这使得使用常用协议(如HTTP / 1.1)启动连接成为可能,然后请求连接切换到HTTP / 2或甚至到WebSocket。

握手

协议升级总是由客户请求; 没有为服务器提供请求协议更改的机制。当客户机希望升级到新的协议,它通过发送任何类型的正常请求发送到服务器(这样做GETPOST等)。但是,该请求需要专门配置以包含升级请求。

特别是,请求需要这两个额外的头文件:

Connection: UpgradeConnection头被设置为"Upgrade"以表示的升级要求。Upgrade: protocols所述Upgrade标头指定的一个或多个以逗号分隔的协议名称,首选项的顺序。

根据请求的协议,可能需要其他头文件; 例如,WebSocket升级允许额外的头部配置关于WebSocket连接的细节,并在打开连接时提供一定程度的安全性。有关更多详细信息,请参阅升级到WebSocket连接。

服务器可拒绝升级-在这种情况下,它仅仅是忽略了"Upgrade"头并发送回一个普通的响应("200 OK"如果它可以提供所请求的资源时,30x如果它要执行重定向,状态码40x50x一个如果不能提供请求的资源) - 或接受升级。在这种情况下,它会发送一个"101 Switching Protocols"带有升级标头的指定所选协议的标头。

在发送101状态码之后,如果新协议要求它发生新的协议的最终握手,则服务器"Upgrade"按照新的协议规则发送原始请求(包括标头的请求)所请求的答案。

101状态码

101状态代码被发送作为对包括一个请求的响应"Upgrade"报头以信号通知请求的接收方愿意升级到所期望的协议之一。如果"101 Switching Protocols"状态码被返回,则标题还必须包含描述所选协议的标题ConnectionUpgrade标题。请参阅此机制的常见用法中的示例,以了解有关这种机制的更多信息。

虽然您可以使用协议升级机制将HTTP / 1.1连接升级到HTTP / 2,但您不能以其他方式。实际上,HTTP / 2不再支持101状态码,因为HTTP / 2没有升级机制。

这种机制的共同用途

这里我们看一下Upgrade头部最常见的用例。

升级到HTTP/2连接

由于其广泛的支持,使用HTTP / 1.1启动连接的标准过程是,然后请求升级到HTTP / 2。这样,即使服务器不支持HTTP / 2,仍然可以正常工作。但是,只能升级到不安全(明文)HTTP / 2连接。这是通过使用目标协议名称来完成的h2c,该名称代表“HTTP / 2 Cleartext”。这也需要指定HTTP2-Settings标题字段。

GET / HTTP/1.1Host: destination.server.ext
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: base64EncodedSettings

这里base64EncodedSettings是一个HTTP / 2 "SETTINGS"帧的有效载荷,它已经被base64url编码,所有的尾随"="(等于)字符被删除,以便将其安全地包含在这个文本标题格式中。

所述base64url格式是不一样的标准Base64编码。这与标准的Base64差不多,但不完全相同。唯一的区别:为了确保所得到的字符串是在URL和文件名使用安全的字母表中的第62和第63个字符从改变"+""/""-"(负)和"_"(下划线),分别。

如果服务器由于某种原因无法切换到HTTP / 2,那么在正常处理请求后,它将回复标准的HTTP / 1回复。因此,如果请求是获取事实上存在的网页,那么您将"HTTP/1.1 200 OK"在网页的其余部分之后获得标准响应。如果服务器能够切换到HTTP / 2,HTTP/1.1 101 Switching Protocols"则会发送一个“ 响应” ,如下所示:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c[standard HTTP/2 server connection preface, etc.]

在HTTP / 1.1头部和指示头部结尾的空白行之后,服务器将立即包含服务器连接前言,从一个SETTINGS帧开始。

升级到WebSocket连接

到目前为止,升级HTTP连接最常见的用例是使用WebSocket,它通常通过升级HTTP或HTTPS连接来实现。请记住,如果您使用WebSocket API或任何执行WebSocket的库打开新连接,则大部分或所有这些都是为您完成的。例如,打开WebSocket连接非常简单:

webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");

WebSocket()构造函数创建一个初始的HTTP / 1.1连接,然后处理握手和升级过程中的所有工作。

您也可以使用"wss://"URL方案打开安全的WebSocket连接。

如果您需要从头开始创建WebSocket连接,则必须自己处理握手过程。在创建初始HTTP / 1.1会话之后,您需要通过添加标准请求UpgradeConnection头部来请求升级,如下所示:

Connection: Upgrade
Upgrade: websocket

WebSocket-特定的头文件

WebSocket升级过程涉及以下头文件。除了头文件UpgradeConnection头文件,其余的文件通常都是可选的,或者在浏览器和服务器互相通话时为您处理。

Sec-WebSocket-Extensions

指定要求服务器使用的一个或多个协议级WebSocket扩展。Sec-WebSocket-Extension允许在请求中使用多个头部; 结果与您在一个这样的标题中包含所有列出的扩展名相同。

Sec-WebSocket-Extensions: extensions

extensions用逗号分隔的请求(或同意支持)的扩展名列表。这些应该从IANA WebSocket扩展名注册表中选择。带参数的扩展使用分号描述。

例如:

Sec-WebSocket-Extensions: superspeed, colormode; depth=16

Sec-WebSocket-Key

向服务器提供信息,以确认客户端有权请求升级到WebSocket。当不安全(HTTP)客户希望升级时,可以使用此头文件,以提供一定程度的防范滥用保护。使用WebSocket规范中定义的算法计算密钥的值,因此不提供安全性。相反,它有助于防止非WebSocket客户端无意中或通过滥用请求WebSocket连接。从本质上说,这个关键只是确认“是的,我真的打算打开一个WebSocket连接。”

这个标题是由选择使用它的客户端自动添加的; 它不能使用该XMLHttpRequest.setRequestHeader()方法添加。

Sec-WebSocket-Key: key

key此请求升级的关键。如果客户希望这样做,则客户端会添加该服务器,并且服务器会在响应中包含自己的密钥,客户端会在向您提供升级响应之前验证该密钥。

服务器的响应Sec-WebSocket-Accept头将有一个基于指定的值计算出来的值key

Sec-WebSocket-Protocol

Sec-WebSocket-Protocol头指定要使用,按优先顺序的一个或多个的WebSocket协议。服务器支持的第一个服务器将被选中,并由服务器在Sec-WebSocket-Protocol响应中包含的标题中返回。您也可以在标题中多次使用它,结果与在单个头中使用逗号分隔的子协议标识符列表相同。

Sec-WebSocket-Protocol: subprotocols

subprotocols按照优先顺序,按逗号分隔的子协议名称列表。子协议可以从IANA WebSocket子协议名称注册中选择,也可以是客户和服务器共同理解的定制名称。

Sec-WebSocket-Version

请求标题

指定客户端希望使用的WebSocket协议版本,以便服务器可以确认该版本是否受支持。

Sec-WebSocket-Version: version

version客户端希望在与服务器通信时使用的WebSocket协议版本。此号码应为IANA WebSocket版本号注册表中列出的最新版本。WebSocket协议的最新最终版本是版本13。

响应标题

如果服务器无法使用指定版本的WebSocket协议进行通信,它将响应一个错误(如需要升级426),在其标题中包含一个包含Sec-WebSocket-Version受支持协议版本的逗号分隔列表的标题。如果服务器确实支持所请求的协议版本,Sec-WebSocket-Version则响应中不会包含标题。

Sec-WebSocket-Version: supportedVersions

supportedVersions服务器支持的WebSocket协议版本的逗号分隔列表。

仅响应头文件

服务器的响应可能包括这些。

Sec-WebSocket-Accept

在服务器愿意启动WebSocket连接时,在打开握手过程期间包含在服务器的响应消息中。它在repsonse头文件中只会出现一次。

Sec-WebSocket-Accept: hash

hash如果Sec-WebSocket-Key提供了头文件,则通过获取该密钥的值来计算此头文件的值,并将字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”连接到该字符串,并取该连接字符串的SHA-1散列值,结果在一个20字节的值。然后该值被base64编码以获得该属性的值。

客户端的启动通过TLS升级到HTTP

您也可以将HTTP / 1.1连接升级到TLS / 1.0。这样做的主要优点是可以避免在服务器上使用从“http://”到“https://”的URL重定向,并且可以在虚拟主机上轻松使用TLS。但是,这可能会导致代理服务器出现问题。

升级HTTP连接以使用TLS将Upgrade标记与标记一起使用"TLS/1.0"。如果交换机成功完成,原始请求(包括其中Upgrade)将按照正常完成,但在TLS连接上完成。

对TLS的请求可以选择性地或强制性地进行。

可选升级

要升级到TLS(也就是说,如果升级到TLS失败,允许连接继续以明文方式),只需按预期方式使用UpgradeConnection标题。例如,给出原始请求:

GET http://destination.server.ext/secretpage.html HTTP/1.1Host: destination.server.ext
Upgrade: TLS/1.0Connection: Upgrade

如果服务器支持TLS升级,或者无法在当时升级到TLS,则它会使用标准的HTTP / 1.1响应进行响应,例如:

HTTP/1.1 200 OK
Date: Thu, 17 Aug 2017 21:07:44 GMT
Server: Apache
Last-Modified: Thu, 17 Aug 2017 08:30:15 GMT
Content-Type: text/html; charset=utf-8Content-Length: 31374<html>  ...</html>

如果服务器确实支持TLS升级并希望允许升级,它将使用"101 Switching Protocols"响应代码进行响应,如下所示:

HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1

一旦TLS握手完成,原始请求将被正常响应。

强制升级

要请求强制升级到TLS(即升级失败并在升级失败时连接失败),您的第一个请求必须是一个OPTIONS请求,如下所示:

OPTIONS * HTTP/1.1Host: destination.server.ext
Upgrade: TLS/1.0Connection: Upgrade

如果升级到TLS成功,服务器将"101 Switching Protocols"按照上一节所述进行响应。如果升级失败,HTTP / 1.1连接将失败。

服务器的启动升级到TLS

这与客户端启动的升级大致相同,通过将Upgrade头添加到任何消息来请求可选的升级。然而,强制升级的工作方式稍有不同,因为它会通过回复收到的带有426状态码的消息来请求升级,如下所示:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.1, HTTP/1.1Connection: Upgrade<html>... Human-readable HTML page describing why the upgrade is required
    and what to do if this text is seen ...</html>

如果接收到"426 Upgrade Required"响应的客户端愿意且能够升级到TLS,则应该启动上面在客户端启动的升级到TLS的过程中所述的相同过程。

参考

  • WebSocket API

  • HTTP

  • 规格和RFC:

    • RFC 2616

    • RFC 6455

    • RFC 2817

    • RFC 7540

在MDN上编辑此页面

上一篇: 下一篇: