Hypertext Transfer Protocol -- HTTP/1.1

HTTP

 

1 介绍

1.1 目的

1.2 需求

1.3 术语

1.4 总体操作

2 符号约定和通用语法 

2.1 增强BNF

2.2 基本规则

3 协议参数

3.1 HTTP版本

3.2 统一资源描述符

3.2.1 通用语法

3.2.2 http URL

3.2.3 URI比较

3.3 日期/时间格式

3.3.1 完整日期

3.3.2 Delta秒

3.4 字符集

3.4.1 丢失字符集

3.5 内容编码

3.6 传输编码

3.6.1 分块传输编码

3.7 媒体类型

3.7.1 默认的标准化和文本化

3.7.2 Multipart类型

3.8 产品标记

3.9 特征值

3.10 语言标签

3.11 实体标签

3.12 区间单元

4 HTTP消息

4.1 消息类型

4.2 消息头部

4.3 消息体

4.4 消息长度

4.5 通用头字段

5 请求

5.1 请求行

5.1.1 方法

5.1.2 请求URI

5.2 请求的资源标识

5.3 请求头字段

6 响应

6.1 状态行

6.1.1 状态码和错误描述

6.2 响应头字段

7 实体

7.1 实体头字段

7.2 Entity体

7.2.1 类型

7.2.2 实体长度

8 连接

8.1 持久连接

8.1.1 目的

8.1.2 总体操作

8.1.3 代理服务器

8.1.4 实际考虑

8.2 消息传输要求

8.2.1 持久连接和控制流

8.2.2 监控错误状态消息的连接

8.2.3 100(继续)状态的使用

8.2.4 服务器贸然关闭连接时的客户端行为

9 方法定义

9.1 安全和幂等方法

9.1.1 安全方法

9.1.2 幂等方法

9.2 OPTIONS

9.3 GET

9.4 HEAD

9.5 POST

9.6 PUT

9.7 DELETE

9.8 TRACE

9..9 CONNECT

10 状态码定义

10.1 表示报告的1xx

10.1.1 100 Continue(继续)

10.1.2 101 Switching Protocols(交换协议)

10.2 表示成功的2xx

10.2.1 200 OK

10.2.2 201 Created

10.2.3 202 Accepted

10.2.4 203 Non-Authoritative Information

10.2.5 204 No Content

10.2.6 205 Reset Content

10.2.7 206 Partial Content

10.3 表示重定向的3xx

10.3.1 300 Multiple Choices

10.3.2 301 Moved Permanently

10.3.3 302 Found

10.3.4 303 See Other

10.3.5 304 Not Modified

10.3.6 305 Use Proxy

10.3.7 306 (Unused)

10.3.8 307 Temporary Redirect

10.4 表示客户端错误的4xx

10.4.1 400 Bad Request

10.4.2 401 Unauthorized

10.4.3 402 Payment Required

10.4.4 403 Forbdden

10.4.5 404 Not Found

10.4.6 405 Method Not Allowed

10.4.7 406 Not Acceptable

10.4.8 407 Proxy Authentication Required

10.4.9 408 Request Timeout

10.4.10 409 Conflict

10.4.11 410 Gone

10.4.12 411 Length Required

10.4.13 412 Preconditon Failed

10.4.14 413 Request Entity Too Large

10.4.15 414 Request-URI Too Long

10.4.16 415 Unsupported Media Type

10.4.17 416 Requested Range Not Satisfiable

10.4.18 417 Expectation Failed

10.5 表示服务器错误的5xx

10.5.1 500 Internal Server Error

10.5.2 501 Not Implemented

10.5.3 502 Bad Gateway

10.5.4 503 Service Unavailable

10.5.5 504 Gateway Timeout

10.5.6 505 HTTP Version Not Supported

11 访问认证

内容协商

HTTP中的缓存

头部字段

安全考虑

感谢 

引用

作者联系方式

附录 

索引

版权声明 

 

1 介绍

1.1 目的

超文本传输协议(HTTP)是一个用于分布式的，协作的，超媒体信息系统的应用层协议。自1990年倡议的万维网全球信息一直在使用HTTP。HTTP的第一个版本，称为HTTP/0.9，是一个简单的协议，用于跨互联网的原始数据传输。RFC 1945 [6]定义的HTTP/1.0 改进了协议，允许消息以类似MIME的消息格式存在，其中包含关于传输数据的元信息以及请求/响应语义上的修饰符。然而，HTTP/1.0没有充分考虑到分层代理、缓存、必要的持久连接或虚拟主机的影响。此外，由于不完全实现的自称为“HTTP/1.0”的应用程序激增，需要对协议版本进行更改，以便两个通信应用程序确定彼此的真正能力。

 

此规范定义的协议被称为"HTTP/1.1"。为了保证有效的实现它的功能，此协议包含比HTTP/1.0更多的严格要求。

 

实用的信息系统比简单的检索需要更多的功能，包括搜索、前端更新和注解。HTTP允许一组开放式的方法和头部以表示请求[47]的意图。它建立在以定位(URL)[4]或名称(URN)[20]的统一资源标识符(URI)[3]提供的引用约束的基础上，用于表示要应用方法的资源。 消息传递的格式类似于多用途Internet邮件扩展(MIME)[7]定义的Internet邮件使用的格式[9]。

 

HTTP还被用作用户代理和代理/网关与其他Internet系统之间通信的通用协议，包括SMTP[16]、NNTP[13]、FTP[18]、Gopher[2]和WAIS[10]协议支持的协议。 这样，HTTP允许基本的超媒体访问来自不同应用程序的可用资源。

 

1.2 需求

 

1.3 术语

本规范使用许多术语来表示HTTP通信的参与者和对象所扮演的角色。

 

connection

 

message

 

request

response

 

resource

 

entity

 

representation

 

content negotiation

 

variant

 

client

 

user agent

 

server

 

origin server

 

proxy

 

gateway

 

tunnel

 

cache

 

cacheable

 

first-hand

 

explicit expiration time

 

heuristic expiration time

 

age

 

freshness lifetime

 

fresh

 

stale

    如果一个响应的年龄(age)已经超过了它的保鲜期，这个响应就是过时的。

 

semantically transparent

 

validator

 

upstream/downstream

    Upstream和Downstream描述消息流：所有的消息流从Upstream到Downstream.

 

inbound/outbound

    Inbound和Outbound是指消息的请求和响应路径：“Inbound”是指“向原点服务器移动”，“Outbound”是指“向用户代理移动”

 

1.4 总体操作

 

2 符号约定和通用语法

2.1 增强的BNF

此文档规范的所有机制都以散文和类似于rfc822[9]中的增强的Backus-Naur Form (BNF) 进行描述。为了理解此规范，实现者必须熟悉这些符合。增强的BNF包含以下构造：

name = definition

    规则的名称只是简单的对自己进行命名（没有任何括号“<”和">"）,name及其definition通过"="进行分隔。

 

"literal"

引号引起来的字面文本。除非另有说明，否则文本不区分大小写。

 

rule1 | rule2

 

 

(rule1 rule2)

 

*rule

 

[rule]

 

N rule

 

#rule

 

; comment

 

implied *LWS

 

2.2 基本规则

 

OCTET = <any 8-bit sequence of data>

CHAR = <any US-ASCII character (octets 0 - 127)>

UPALPHA = <any US-ASCII uppercase letter "A".."Z">

LOALPHA = <any US-ASCII lowercase letter "a".."z">

ALPHA = UPALPHA | LOALPHA

DIGIT = <any US-ASCII digit "0".."9">

CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>

CR = <US-ASCII CR, carriage return (13)>

LF = <US-ASCII LF, linefeed (10)>

SP = <US-ASCII SP, space (32)>

HT = <US-ASCII HT, horizontal-tab (9)>

<"> = <US-ASCII double-quote mark (34)>

 

HTTP/1.1为所有的协议元素定义CR LF作为行结束（end-of-line）的标识，entity-body (see appendix 19.3 for tolerant applications)除外。entity-body中的行结束（end-of-line）的标识由其相关的媒体类型定义。在3.7章节中有描述。

 

CRLF = CR LF

 

 

3 协议参数

3.1 HTTP版本

 

HTTP使用一种“<主版本号>.<小版本号>”(“<major>.<minor>”)的版本方式来表示协议的版本。协议的这种版本策略目的并不是获得通信中的特征，而是为了允许发送者指定消息格式以及能力，以便理解将来的HTTP通信。对于附加消息组件，版本号不改变，不会影响通信行为，或者只加到扩展字段值中。如果协议加了新功能，但不影响通用消息的解析，但可能添加到消息语义中并且含有发送者额外的能力，次版本号<minor>将增长。如果协议中的消息格式变更了，<major>主版本号将增长。完整说明参考RFC 2145 [36]。

 

HTTP消息的版本由HTTP-Version字段指定，该字段在消息中的首行。

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 

 

注意，主版本和小版本必须分开处理，并且这两个版本号可能依次增长。那么，HTTP/2.4比HTTP/2.13版本低，HTTP/2.13比HTTP/12.3版本低。接收者必须忽略前面的0，并且不需要发送。

 

发送一个包含"HTTP/1.1"HTTP版本的请求或响应消息的应用，应用必须至少有条件兼容此规范。至少有条件兼容此规范的应用应该在消息中使用"HTTP/1.1"HTTP版本，对于其他不兼容HTTP/1.0的任何消息也必须这么做。当发送指定HTTP版本时，详细参考RFC 2145 [36]。

 

应用的HTTP版本至少为应用有条件兼容的最高HTTP版本。

 

代理和网关应用必须注意，当转发消息的时候，如果协议版本和应用的协议版本存在差异的情况。因为协议版本决定了发送者的协议能力，代理/网关不可以发送一条指定版本大于实际版本的消息。如果接收到了更高版本的请求，代理/网关必须对请求的版本降级，或者响应一个错误，或者转给隧道。

 

鉴于RFC 2068[33] 发布的 HTTP/1.1协议存在着和HTTP/1.0代理的互操作性问题，缓存代理服务器必须[MUST]将请求升级到自己能支持的最高版本，网关服务器也可能要这么做，隧道系统不可以这么做。代理/网关对该请求的响应的主版本号必须和请求中的主版本号相同。

 

注意，HTTP版本的转换可能涉及头字段修改，这些头字段的修改可能是对应版本必须的或者不被允许的。

 

3.2 统一资源标识符

 

URI有很多其他的名字：万维网地址（WWW地址），统一文档标识符，统一资源标识符，以及统一资源定位器(URL)和命名(URN)的组合。自从HTTP被关注后，统一资源定位符通过命名名称，定位地址或者其他任何特征(如某种资源)标识的简单的格式化字符串表示。

 

3.2.1 通用语法

 

HTTP中的统一资源定位符(URI)可以表示为绝对格式或者相对格式，根据使用的上下文，基于某个基准URI而表示的相对格式。这两种格式辨别的依据就是绝对格式总是由一个协议“http”名称后跟一个冒号“:”开始。有关URL的语法和语义的约定，可参考RFC 2396 [42]  “Uniform Resource Identifiers (URI): Generic Syntax and Semantics, ”。本规范采用的是RFC 2396 [42]中的“URI-reference”, “absoluteURI”, “relativeURI”, “port”, “host”,“abs_path”, “rel_path”, and “authority”的约定。

 

HTTP协议不会给URI的长度指定任何预设限制，服务器必须能够处理他们能处理的任何资源的URI，并且如果服务器支持基于GET生成的无限长度的URI，服务器应该能够处理这样的URI。如果URI太长，服务器无法处理，服务器应该返回414（Request-URI Too Long）状态。

 

3.2.2 HTTP URL

 

“http”提案用于通过HTTP协议定位网络资源。这章将为HTTP URL定义提案相关的语法和语义。

 

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

 

如果port为空或者没有指定，默认port为80。其语义为标识的资源在服务器在指定端口监听TCP连接的主机上，并且资源的Request-URI为abs_path。应该尽可能避免在URL中使用IP地址。如果URL中没有abs_path，必须使用"/"作为资源的Request-URI。如果代理接收到一个HTTP URL请求，其host不是一个完备的域名，代理可能将自己的域加入到接收的host中。如果代理接收到一个完备的域名，代理不可以改变host。

 

3.2.3 URI比较

 

当比较两个URI，以判断它们是否匹配时，客户端应该使用大小写敏感，8为字节逐个比较整个URI， 即case-sensitive octet-by-octet comparison，下面是一些例外情况：

 

  - 如果port为空或者没有指定，等同于默认端口

  - host的比较必须是大小写敏感的

  - scheme的比较必须是大小写敏感的

  - 如果abs_path为空，等同于"/"

 

除保留（"reserved"）和不安全（"unsafe"）之外的字符等同于它们的""%" HEX HEX"编码。

例如，下面3个URI是等同的：

  http://abc.com:80/~smith/home.html

  http://ABC.com/%7Esmith/home.html

  http://ABC.com:/%7esmith/home.html

 

3.3 日期/时间格式

3.3.1 完整日期

3.3.2 Delta Seconds 

 

一些HTTP头字段允许一个时间值指定为一个整型数的秒数，通过decimal表示

 

delta-seconds = 1*DIGIT

 

3.4 字符集

3.4.1 遗失的字符集

 

一些HTTP/1.0软件错误地将没有charset参数的Content-Type头解释为“recipient should guess”

 

发送者希望阻止这种行为，可能包含一个charset参数，尽管charset是ISO-8859-1，并且在知道这样不会混淆接收者的情况下，应该这么做

 

不幸的是，一些老的HTTP/1.0客户端没有正确处理显式charset参数。HTTP/1.1接收者必须认可发送者提供的charset

 

3.5 内容编码

 

内容编码值表示一个已经或可以应用于一个entity实体的编码转换。内容编码主要用于在不丢失其底层媒体类型的标识和不丢失信息的情况下压缩或以其他方式有效地转换文档。通常，实体以编码形式存储，直接传输，并且只由接收者解码。

 

content-coding = token

 

gzip  文件压缩程序"gzip" (GNU zip)提供的一中编码格式。"gzip" (GNU zip)在RFC 1952 [25]中有描述。这种格式是一种使用32位CRC的Lempel-Ziv编码(LZ77)

 

compress

        UNIX文件压缩程序"compress"提供的编码格式。这种格式是一种自适应的Lempel-Ziv-Welch编码（LZW）。

 

deflate

        RFC 1950 [31]中定义的"zlib"格式，结合RFC 1951[29]中描述的"deflate"压缩机制

 

identity

        默认(identity)编码

 

3.6 传输编码

传输编码值用于表示已被，可以被，或者可能需要被应用于entity-body转换的编码，以便保证通过网络"安全运输"。这不同于内容编码，因为传输编码是消息的属性，而不是原始实体的属性。

 

       transfer-coding         = "chunked" | transfer-extension

       transfer-extension      = token *( ";" parameter )

 

参数为属性/值对形式。

 

       parameter               = attribute "=" value

       attribute               = token

       value                   = token | quoted-string

 

所有的传输编码值是大小写不敏感的。HTTP/1.1在TE头字段（第14.39章节）和Transfer-Encoding头字段（第14.41章节）中使用传输编码值。

 

每当将传输编码应用于消息体时，传输编码集必须包括"chunked"，除非通过关闭连接终止消息。 当使用"chunked"传输编码时，它必须是应用于消息体的最后一个传输编码。 "chunked"传输编码不能不止一次地应用于消息体。 这些规则允许接收者确定消息的传输长度（4.4节）。

 

传输编码类似于MIME[7]的Content-Transfer-Encoding值，它的设计是为了能够在7位传输服务上安全地传输二进制数据。 然而，对于纯8位传输协议，安全传输有不同的重点。 在HTTP中，消息体的唯一不安全特性是难以确定确切的主体长度（第7.2.2节），或者希望通过共享传输加密数据。

 

互联网号码分配管理局(IANA)充当传输编码值标识的注册中心。 最初，注册中心包含以下标识：“chunked”（第3.6.1节）、“identity”（第3.6.2节）、“gzip”（第3.5节）、“compress”（第3.5节）和“deflate”（第3.5节）。

 

新的传输编码值标识应该以同样的方式作为新的内容编码值标识（第3.5章节）注册。

 

服务器接收了一个无法识别的传输编码的entity-body，应该返回501（Unimplemented），并且关闭连接。服务器不可以给HTTP/1.0客户端发送传输编码。

 

3.6.1 分块传输编码

分块编码修改消息体，以便将其作为一系列块传输，每块都有自己的大小指示，后面跟一个包含实体头字段的可选（OPTIONAL）trailer。这允许动态生成的内容和接收者验证已收到完整消息所需要的信息一起传输。

 

       Chunked-Body   = *chunk

                        last-chunk

                        trailer

                        CRLF

 

       chunk          = chunk-size [ chunk-extension ] CRLF

                        chunk-data CRLF

       chunk-size     = 1*HEX

       last-chunk     = 1*("0") [ chunk-extension ] CRLF

 

       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

       chunk-ext-name = token

       chunk-ext-val  = token | quoted-string

       chunk-data     = chunk-size(OCTET)

       trailer        = *(entity-header CRLF)

 

chunk-size字段是一个16进制数字的字符串，表示块的大小。分块编码通过一个块大小为0的块结束，后跟trailer，通过一个空行结束。

 

trailer允许发送者在消息的后面包含附加的HTTP头字段。Trailer头字段可以用于表示哪些头字段包含在trailer（参考第14.40章节）中。

 

服务器在响应中使用分块传输编码不可以对任何头字段使用trailer，除非至少满足以下任一条件：

 

a)请求包含一个TE头字段，以指示在响应的传输编码中"trailers"是可接受的，如第14.39章节中描述；或者，

 

b)服务器是响应的源服务器，trailer字段完全由可选的元数据组成，并且接收者不接收此元数据就可以使用消息（以源服务器可以接受的方式）。换句话说，源服务器接受这样的可能性，即trailer字段可能沿着到客户端的路径被默默地丢弃。

 

当消息被HTTP/1.1（或更高版本）代理接收并转发给HTTP/1.0接收者时，此要求防止互操作性失败。 它避免了在遵守协议的情况下需要在代理上设置可能无限的缓冲区。

 

附录19.4.6给出了一个解码Chunked-Body的示例过程。

 

所有HTTP/1.1应用必须能接收和解码"chunked"传输编码，且必须忽略无法识别的chunk-extension扩展。

 

3.7 媒介类型

3.7.1 标准化及缺省文本

3.7.2 Multipart类型

3.8 产品标识 

3.9 质量值 

3.10 语言标签 

3.11 实体标签 

3.12 Range单位

 

4 HTTP消息

 

4.1 消息类型

HTTP消息由从客户端到服务器的请求和从服务器到客户端的响应组成。

 

    HTTP-message   = Request | Response     ; HTTP/1.1 messages

 

请求和响应消息使用RFC 822 [9]的通用消息格式来传输实体（消息的有效荷载）。每种类型的消息由一个起始行，零个或多个头字段（也称为头），一个空行（例如，一个由CRLF开始没有任何东西的行）表示头字段的结束，还有可能带一个消息体。

    generic-message = start-line

                          *(message-header CRLF)

                          CRLF

                          [ message-body ]

 

    start-line      = Request-Line | Status-Line

 

4.2 消息头

 

4.3 消息体

 

4.4 消息长度

 

4.5 通用头字段

 

 

 

5 请求

 

从客户端到服务器的请求消息包括，在消息的起始行中，应用于资源的方法，资源的标识，以及使用的协议版本。

 

Request       = Request-Line              ; Section 5.1

                        *(( general-header        ; Section 4.5

                         | request-header         ; Section 5.3

                         | entity-header ) CRLF)  ; Section 7.1

                        CRLF

                        [ message-body ]          ; Section 4.3

 

5.1 请求行

Request-Line以一个方法token开始，后跟Request-URI以及协议版本，最后以CRLF作为结束。它们通过空格(SP)分隔。除了最后的CRLF，不允许有CR或LF。

 

    Request-Line = Method SP Request-URI SP HTTP-Version CRLF

 

5.1.1 方法

Method指定在Request-URI标识的资源执行的方法。方法是大小写敏感的。

 

    Method         = "OPTIONS"                ; Section 9.2

                      | "GET"                    ; Section 9.3

                      | "HEAD"                   ; Section 9.4

                      | "POST"                   ; Section 9.5

                      | "PUT"                    ; Section 9.6

                      | "DELETE"                 ; Section 9.7

                      | "TRACE"                  ; Section 9.8

                      | "CONNECT"                ; Section 9.9

                      | extension-method

 

    extension-method = token

 

资源允许的方法列表可以指定在Allow头字段（14.7章节）中。响应的返回状态码总是告知客户端当前在该资源上是否允许该方法，因为允许的方法集可以动态的改变。如果源服务器识别该方法，但请求的资源不允许该方法，源服务器应该返回状态码405（Method Not Allowed）。如果源服务器无法识别，或者没有实现该方法，应该返回状态码501（Not Implemented）。所有通用服务器必须支持GET和HEAD方法。所有其他方法是可选的；但是，如果上面的方法都实现，第9章节中规定的语义，都必须一一实现。

 

5.1.2 请求URI

 

5.2 请求的资源标识符

 

5.3 请求的头字段

 

    request-header = Accept                   ; Section 14.1

                      | Accept-Charset           ; Section 14.2

                      | Accept-Encoding          ; Section 14.3

                      | Accept-Language          ; Section 14.4

                      | Authorization            ; Section 14.8

                      | Expect                   ; Section 14.20

                      | From                     ; Section 14.22

                      | Host                     ; Section 14.23

                      | If-Match                 ; Section 14.24

                      | If-Modified-Since        ; Section 14.25

                      | If-None-Match            ; Section 14.26

                      | If-Range                 ; Section 14.27

                      | If-Unmodified-Since      ; Section 14.28

                      | Max-Forwards             ; Section 14.31

                      | Proxy-Authorization      ; Section 14.34

                      | Range                    ; Section 14.35

                      | Referer                  ; Section 14.36

                      | TE                       ; Section 14.39

                      | User-Agent               ; Section 14.43

 

6 响应

 

    Response      = Status-Line               ; Section 6.1

                       *(( general-header        ; Section 4.5

                        | response-header        ; Section 6.2

                        | entity-header ) CRLF)  ; Section 7.1

                       CRLF

                       [ message-body ]          ; Section 7.2

 

6.1 状态行

 

6.1.1 状态码和错误描述

 

    Status-Code    =

            "100"  ; Section 10.1.1: Continue

          | "101"  ; Section 10.1.2: Switching Protocols

          | "200"  ; Section 10.2.1: OK

          | "201"  ; Section 10.2.2: Created

          | "202"  ; Section 10.2.3: Accepted

          | "203"  ; Section 10.2.4: Non-Authoritative Information

          | "204"  ; Section 10.2.5: No Content

          | "205"  ; Section 10.2.6: Reset Content

          | "206"  ; Section 10.2.7: Partial Content

          | "300"  ; Section 10.3.1: Multiple Choices

          | "301"  ; Section 10.3.2: Moved Permanently

          | "302"  ; Section 10.3.3: Found

          | "303"  ; Section 10.3.4: See Other

          | "304"  ; Section 10.3.5: Not Modified

          | "305"  ; Section 10.3.6: Use Proxy

          | "307"  ; Section 10.3.8: Temporary Redirect

          | "400"  ; Section 10.4.1: Bad Request

          | "401"  ; Section 10.4.2: Unauthorized

          | "402"  ; Section 10.4.3: Payment Required

          | "403"  ; Section 10.4.4: Forbidden

          | "404"  ; Section 10.4.5: Not Found

          | "405"  ; Section 10.4.6: Method Not Allowed

          | "406"  ; Section 10.4.7: Not Acceptable

          | "407"  ; Section 10.4.8: Proxy Authentication Required

          | "408"  ; Section 10.4.9: Request Time-out

          | "409"  ; Section 10.4.10: Conflict

          | "410"  ; Section 10.4.11: Gone

          | "411"  ; Section 10.4.12: Length Required

          | "412"  ; Section 10.4.13: Precondition Failed

          | "413"  ; Section 10.4.14: Request Entity Too Large

          | "414"  ; Section 10.4.15: Request-URI Too Large

          | "415"  ; Section 10.4.16: Unsupported Media Type

          | "416"  ; Section 10.4.17: Requested range not satisfiable

          | "417"  ; Section 10.4.18: Expectation Failed

          | "500"  ; Section 10.5.1: Internal Server Error

          | "501"  ; Section 10.5.2: Not Implemented

          | "502"  ; Section 10.5.3: Bad Gateway

          | "503"  ; Section 10.5.4: Service Unavailable

          | "504"  ; Section 10.5.5: Gateway Time-out

          | "505"  ; Section 10.5.6: HTTP Version not supported

          | extension-code

 

    extension-code = 3DIGIT

 

    Reason-Phrase  = *<TEXT, excluding CR, LF>

 

6.2 响应头字段

 

 

7 实体

 

7.1 实体头部字段

7.2 Entity体

7.2.1 类型

 

当实体包体包含了一条消息，包体的消息数据类型由头部字段Content-Type和Content- Encoding决定。它们定义一个两层的，排序的编码模式：

entity-body := Content-Encoding( Content-Type( data ) ) 

Content-Type指定表面数据的媒介类型。Content-Encoding可能用于表示任何附加的应用于数据的内容编码，通常出于数据压缩的目的，这个是被请求资源的一个属性。它没有默认编码。

 

任何包含实体包体的HTTP/1.1消息应该包含Content-Type头部字段用于定义包体的媒体类型。如果没有通过Content-Type字段指定媒体类型，接受者可能试图通过检查内容并且或通过标识资源的URI的扩展名来猜测媒体类型。如果媒体类型是未知的，接受者应该把它处理为” application/octet-stream“类型。

 

7.2.2 实体长度

 

 

8 连接

 

8.1 持久连接

 

8.1.1 目的

在持久连接之前，建立一个单独的TCP连接来获取每个URL，这增加了HTTP服务器的负担，并导致Internet上的拥塞。使用内联图像和其他相关数据通常需要客户端在短时间内对同一服务器进行多个请求。对这些性能问题的分析和原型实现的结果可以在[26][30]中获取。实际HTTP/1.1(RFC2068)实现的实现经验和测量显示了良好的结果[39]。 还探讨了替代办法，例如T/TCP[27]。

 

持久HTTP连接有很多优点：

 

    - 通过打开和关闭较少的TCP连接，CPU时间保存在路由器和主机（客户端，服务器，代理，网关，隧道或缓存）中，用于TCP协议控制块的内存可以保存在主机中。

 

    - HTTP请求和响应可以在连接上流水线化管道化。 管道化允许客户端在不等待每个响应的情况下发出多个请求，允许更有效地更低毫时的使用单个TCP连接。

 

    - 通过减少TCP打开引起的数据包数量，以及通过允许TCP有足够的时间来确定网络的拥塞状态，从而减少网络拥塞。

 

    - 由于没有花费时间在TCP的连接打开握手，因此减少了后续请求的延迟。

 

    - HTTP可以更优雅地进化，因为可以报告错误而不需要关闭TCP连接。 使用HTTP未来版本的客户端可能会乐观地尝试新功能，但是如果与以前的老服务器通信，则在报告错误后用以前的语义重试。

 

HTTP实现应该实现持久连接。

 

8.1.2 总体操作

HTTP/1.1和HTTP的早期版本之间的一个显著区别是，持久连接是任何HTTP连接的默认行为。 也就是说，除非另有说明，客户端应该假设服务器将保持持久连接，即使在服务器的错误响应之后。

 

持久性连接提供了一种机制，通过这种机制，客户端和服务器可以发出TCP连接关闭的信号。 此信令使用Connection头字段（第14.10节)进行。 一旦发出关闭信号，客户端就不能在该连接上再发送任何请求。

 

8.1.2.1 协商

HTTP/1.1服务器可能假设HTTP/1.1客户端期望维持持久连接除非发送的请求中的Connection头包含"close"连接标识。如果服务器在发送响应后选择立即关闭连接，服务器应该发送一个包含"close"连接标识的Connection头。

 

HTTP/1.1客户端可能期望连接保持打开状态，但会根据来自服务器的响应是否包含"close"连接标识的Connection头而决定保持其打开状态。 如果客户端不想在该请求完成后维护连接，它应该发送一个包含"close"连接标识的Connection头。

 

如果客户端或服务器发送close连接标识的Connection头，对于该连接，该请求将是最后一个。

 

对于小于1.1的HTTP版本，客户端和服务器不能假设会保持持久连接，除非它被显式地发出信号。 有关与HTTP/1.0客户端的向后兼容性的更多信息，请参见第19.6.2节。

 

为了保持持久性，连接上的所有消息必须具有自定义消息长度，如4.4节所述。

8.1.2.2 流水线化/管道化

支持持久连接的客户端可能“流水线化/管道化”它的请求（例如，发送多个请求而不需要等待每个响应）。服务器必须按照这些请求接收的顺序去发送这些请求对应的响应。

 

在建立连接后，立即假定持久连接和管道的客户端，如果第一次流水线化/管道化尝试失败，应该准备重试它们的连接。 如果客户端进行了这样的重试，则在知道连接是持久的之前，它不能进行流水线操作。 如果服务器在发送所有相应响应之前关闭连接，客户端也必须准备重新发送请求。

 

客户端不能使用非幂等方法或非幂等方法序列来处理请求（见9.1.2节）。 否则，过早终止运输连接可能导致不确定的结果。 希望发送非等幂请求的客户端应该等待发送该请求，直到它收到了前一个请求的响应状态。

 

8.1.3 代理服务器

 

8.1.4 实际考虑

 

8.2 消息传输要求

 

8.2.1 持久连接和控制流

 

8.2.2 监控错误状态消息的连接

 

8.2.3 100(继续)状态的使用

 

8.2.4 服务器贸然关闭连接时的客户端行为

 

9 方法定义

 

HTTP/1.1的公共方法集将在后面定义。尽管这个方法集可以扩充，

 

Host请求头字段（第14.23节）必须伴随所有HTTP/1.1请求。

 

9.1 安全和幂等方法

9.1.1 安全方法

 

实现者应该意识到，软件是用户在互联网上的互动，并且应该关心让用户能够知道他们可能采取的任何行动可能对自己或他人有意想不到的影响。 

 

9.1.2 幂等方法

9.2 OPTIONS 

9.3 GET 

 

GET请求方式用于获取由Request-URI标识的任何信息(以一种实体的形式)。如果Request-URI关联的是一个数据生产过程，那么这个Request-URI就是生产的数据，这个生产的数据应该以实体的形式返回到响应当中，而不是这个数据生产过程的原始文本，除非原始文本恰好是这个过程的输出。

 

如果请求消息中包含If-Modified-Since，If-Unmodified-Since，If-Match，If-None-Match或者If-Range头部字段， GET请求方式的语义转变为“条件获取”“conditional GET”。对于一个“条件获取”请求，实体只在条件头部字段描述的环境下传输。 “条件获取”请求的目的是通过允许缓存的实体被刷新，而不需要多次请求或者不必传输已经被客户端持有的数据，以减少不必要的网络开销。

 

如果请求消息中包含Range头部字段， GET请求方式的语义转变为“偏向获取”“partial GET”。一个“偏向获取”请求，只传输实体的一部分，在14.35 章节中被描述。“偏向获取”请求的目的是通过允许完成实体的部分地获取，而不必传输已经被客户端持有的数据，以减少不必要的网络开销。

 

GET请求的响应是可缓存的，除非(只有这种情况)遇到第13章节中描述的HTTP缓存要求。

 

安全考虑可参考15.1.3章节。 

 

9.4 HEAD

 

HEAD这种请求方式和GET请求方式是幂等的，完全一样的，除非服务器在响应中不[MUST NOT]返回消息体。HEAD请求响应中的头部包含的元信息应该[SHOULD]和GET请求响应中的头部包含的元信息是一样的。这种请求方式可以用于获取实体相关的元信息，而不会传输实体内容。这种请求方式通常用于测试超链接的有效性，可访问性，和最近是否有修改。

 

HEAD请求的响应可能[MAY]被缓存，这个意思是说，响应中包含的信息可能[MAY]被用于更新来自这个资源之前缓存的实体。如果新的字段值显示和缓存的实体不同(Content-Length, Content-MD5, ETag或者Last-Modified这几个字段出现变化)，那么缓存必须[MUST]处理缓存条目为过期。

 

9.5 POST

 

POST请求方式用于请求源服务器接收随附在请求中的实体作为Request-Line中的Request-URI标识的资源的新的附属。POST被设计为允许一个统一的方式覆盖以下功能：

    - 已存在的资源的注解

    - 发布一条消息到公告板、新闻组、邮件列表、或一个文章分类

    - 提交一块数据，例如提交表单，到数据处理过程的结果

    - 通过追加操作扩展数据库  

 

POST请求方式实际执行的功能是由服务器决定的，通常取决于请求的URI。提交的实体附属于请求的URI，和一个文件附属于包含它的目录，一篇新文章附属于发布的那个新闻组，或者和一条记录附属于一个数据库类似。

 

9.6 PUT 

 

PUT方式用于请求存储在指定提供的Request-URI下的封闭的实体。如果Request-URI引用的是一个已经存在的资源，这个封闭的实体应该[SHOULD]被视为驻留在源服务器上的一个修改后的版本。 如果Request-URI没有指向一个存在的资源，并且这个URI能够被请求的用户代理定义为新资源，源服务器可以创建这个URI指定的资源。如果一个新资源被创建，源服务器必须以一个201(Created)的响应状态通知用户代理。如果一个存在的资源被修改，应该返回一个200(OK)或者204(No Content)的响应状态以表示成功的处理了这个请求。如果资源不能通过对应的Request-URI创建或修改，应该返回一个恰当的错误响应，返回的错误信息能反映错误的具体原因。实体容器服务器不可以[MUST NOT]忽略任何它不能理解或者没有实现的Content-开头(Content-*, 例如Content-Range)的头部，在这种情况下必须返回一个501(Not Implemented)响应。

 

如果请求通过一个缓存，并且Request-URI标识当前一个或多个缓存的实体，这些实体应该处理为过期。这种请求方式的响应不可缓存。

 

POST和PUT请求的根本区别反映在Request-URI的不同含义。POST请求中的URI表示一个资源， 这个资源将处理封闭的实体。这个资源可能是一个数据接收的过程，一个支持一些其他协议的网关，或者一个接受注解的独立实体。相比之下 ，PUT请求中的URI表示随请求的实体－－用户代理知道什么URI是为特定资源而设计的，服务器不可以[MUST NOT]试图将请求应用到其他资源。如果服务器希望这个请求被应用于不同的URI，服务器必须返回一个301(Moved Permanently)的响应；然后用户代理可能就”是否重定向请求“，作出自己的决定。

 

单个资源可能被很多不同的URI标识，例如，一篇文章可能有一个URI用于标识”当前版本“，这个URI和标识每个单独版本的文章的URI是区分的。在这种情况下，在一个通用URI上的PUT请求可能会导致其他几个由源服务器定义的URI受到影响(如被匹配选择到)。 

 

HTTP/1.1没有定义一个PUT请求会如何影响源服务器的状态。

 

PUT请求必须服从第8.2章节中的信息传输要求。

 

对于特定实体头部，除非另有说明，PUT请求中的实体头部应该被应用于被创建的资源或被PUT请求修改的资源。

 

在这里，请求、实体、资源、URI这个几个概念有什么区别和联系？

 

9.7 DELETE 

9.8 TRACE 

9.9 CONNECT 

 

 

10 状态码定义

 

10.1 表示报告的 1xx

10.1.1 100 Continue 

10.1.2 101 Switching Protocols 

10.2 表示成功的 2xx 

10.2.1 200 OK 

10.2.2 201 Created 

10.2.3 202 Accepted 

10.2.4 203 Non-Authoritative Information 

10.2.5 204 No Content 

10.2.6 205 Reset Content 

10.2.7 206 Partial Content 

10.3 表示重定向的 3xx

10.3.1 300 Multiple Choices 

10.3.2 301 Moved Permanently 

10.3.3 302 Found 

10.3.4 303 See Other 

10.3.5 304 Not Modified 

10.3.6 305 Use Proxy 

10.3.7 306 (Unused) 

10.3.8 307 Temporary Redirect  

 

10.4 表示客户端错误的 4xx 

10.4.1 400 Bad Request 

10.4.2 401 Unauthorized 

10.4.3 402 Payment Required

 

此状态码留作将来使用。

 

10.4.4 403 Forbidden 

10.4.5 404 Not Found 

10.4.6 405 Method Not Allowed 

10.4.7 406 Not Acceptable 

10.4.8 407 Proxy Authentication Required 

10.4.9 408 Request Timeout 

10.4.10 409 Conflict 

10.4.11 410 Gone 

10.4.12 411 Length Required 

10.4.13 412 Precondition Failed 

10.4.14 413 Request Entity Too Large 

10.4.15 414 Request-URI Too Long 

10.4.16 415 Unsupported Media Type 

10.4.17 416 Requested Range Not Satisfiable 

10.4.18 417 Expectation Failed 

 

10.5 表示服务端错误的 5xx 

10.5.1 500 Internal Server Error 

10.5.2 501 Not Implemented 

10.5.3 502 Bad Gateway 

10.5.4 503 Service Unavailable 

10.5.5 504 Gateway Timeout 

10.5.6 505 HTTP Version Not Supported 

 

用于表示报告的状态码 1xx

用于表示成功的状态码 2xx 

用于表示重定向的状态码 3xx

用于表示客户端错误的状态码 4xx

用于表示服务端错误的状态码 5xx

以数字5开头的响应状态码表明服务器意识到出现错误或者无法执行请求的情况。除非是响应一个HEAD请求，服务器应该包含一个实体以包含出现错误状况的解释说明，以及它是一个临时的还是永久的错误条件。用户代理应该显示任何包含的实体给用户。这些响应状态码适用于任何请求方式。

 

 

 

用于表示服务端错误的状态码 5xx 

500 Internal Server Error 

服务器发生了一个意外的条件，这种意外条件阻止它履行请求。 

 

如服务器在处理请求时报错或者出现异常而无法正常处理客户端请求

501 Not Implemented 

服务器不支持某个要求的功能以履行请求。当服务器无法识别客户端的请求方式以及对于任何资源都没有能力支持它。

502 Bad Gateway 

网关服务器或者代理服务器从它访问的试图履行请求的上游服务器(upstream server)接收到一个非法的响应。

503 Service Unavailable 

服务器当前由于临时超载或维护而无法处理请求。其含义是这是一个暂时的条件，经过一段时间的延缓后将会得到解决。如果知道的话，Retry-After头部字段可能[MAY]指定延缓的长度(通常指的是时间长度)。如果没有指定Retry-After，客户端应该处理这个响应，就当它是一个500响应一样。

 

 

11 访问认证

 

12 内容协商

 

12.1 服务器驱动的协商

 

12.2 代理驱动的协商

 

12.3 透明协商

 

13 HTTP缓存

 

13.1.1 缓存正确性

 

13.1.2 警告

 

13.1.3 缓存控制机制

 

13.1.4 显式用户代理警告

 

13.1.5 规则和警告的例外

 

13.1.6 客户端控制的行为

 

13.2 有效期机制

 

13.2.1 服务器指定的有效期

 

13.2.2 启发式过期

 

13.2.3 年龄计算

 

13.2.4 有效期计算

 

13.2.5 消除过期值的歧义

 

13.2.6 消除多响应的歧义

 

13.3 验证模型

 

 

 

14 头部字段定义

14.1 Accept 

 

Accept请求头部字段用于指定那些能够被客户端接受的媒介类型，以便在响应中的Content-Type头部字段中指定一个被客户端接受的媒介类型。 Accept头部可以用来表示请求被明确地限制在一小组期望的媒介类型集合中，如一张内嵌图片请求的情况。

 

Accept               = "Accept" ":" 

                    #( media-range [ accept-params ] )

 

media-range      = ( "*/*" 

       | ( type "/" "*" ) 

       | ( type "/" subtype ) 

       ) *( ";" parameter ) 

 

accept-params   = ";" "q" "=" qvalue *( accept-extension ) 

 

accept-extension = ";" token [ "=" ( token | quoted-string ) ] 

 

星号”*”字符用于对媒介类型进行分组后所在的一个范围，” */* “表示所有的媒介类型，” type/* “表示指定类型type下的所有子类型。 media-range可能包括应用于media-range的媒介类型参数。

 

例如：

Accept: audio/*; q=0.2, audio/basic 

应该解释为：

 

”我更希望给我指定的是audio/basic媒介类型，但是如果质量下降80%后能够保持最好的可用性的话可以给我指定任何audio的媒介类型。“

 

一个比较详细的例子:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c 

照字面地，这将解释为：

”我更希望接受text/html、 text/x-c这几种媒介类型，但是如果质量下降20%后能够保持最好的可用性的话可以给我指定text/x-dvi媒介类型，如果不给我指定text/x-dvi媒介类型的话，如果质量下降50%后能够保持最好的可用性的话可以给我指定text/plain媒介类型。“

 

 

Accept

再一个例子：

Accept: text/*, text/html, text/html;level=1, */* 

 

再一个例子：

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 

 

再一个更详细的例子：

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

应该解释为：

 

”我更希望接受text/html、application/xhtml+xml这几种媒介类型，但是如果质量下降10%后能够保持最好的可用性的话可以给我指定application/xml媒介类型，如果不给我指定application/xml媒介类型的话，如果质量下降20%后能够保持最好的可用性的话可以给我指定任何媒介类型。“

 

14.2 Accept-Charset  

Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) 

 

例子：

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 

 

 

Accept-Encoding 

 

Accept-Encoding = "Accept-Encoding" ":" 

1#( codings [ ";" "q" "=" qvalue ] ) 

 

codings = ( content-coding | "*" ) 

 

例子：

Accept-Encoding: compress, gzip 

Accept-Encoding: 

Accept-Encoding: * 

Accept-Encoding: compress;q=0.5, gzip;q=1.0 

Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 

 

再来一个例子：

Accept-Encoding:gzip,deflate,sdch

 

 

14.3 Accept-Encoding 

14.4 Accept-Language 

 

Accept-Language = "Accept-Language" ":"   1#( language-range [ ";" "q" "=" qvalue ] ) 

 

language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) 

 

例子：

Accept-Language: da, en-gb;q=0.8, en;q=0.7 

 

再来一个例子：

Accept-Language:zh-CN,zh;q=0.8

 

 

 

14.5 Accept-Ranges 

14.6 Age 

14.7 Allow

Allow实体头字段列出Request-URI标识的资源支持的方法集。这个字段的目的是严格告知接收方与资源相关的有效方法。Allow头字段必须出现在405（Method Not Allowed）响应中。

 

    Allow   = "Allow" ":" #Method

 

使用例子：

 

    Allow: GET, HEAD, PUT

 

此字段不能阻止客户端其他方法。然而，应该遵循Allow头字段给出的指示。每次请求时允许的实际方法集由源服务器定义。

 

PUT请求可能提供Allow头字段以要求新资源或者修改过的资源支持这些方法。不要求服务器也支持这些方法，但应该在响应中包含Allow头以给出实际支持的方法。

 

代理即使不能理解这些指定的方法，也不可以修改Allow头字段，因为用户代理可能有其他与源服务器通信的方法。

 

14.8 Authorization 

用户代理希望在收到401响应后和服务器进行身份验证--通常，但不一定是这样--通过在请求中包含一个Authorization请求头字段来实现。Authorization(授权)字段值由包含被请求资源领域（realm，也可以理解为scope，范围）的用户代理的身份验证信息的凭证组成。

 

    Authorization  = "Authorization" ":" credentials

 

在"HTTP Authentication: Basic and Digest Access Authentication" [43]中描述了HTTP访问身份验证。如果一个请求被认证，且指定了领域（realm），对于这个领域（realm）中的其他所有请求，同样的凭证应该都是有效的。

 

当一个共享缓存（参考13.7章节）接收到一个包含Authorization(授权)字段的请求，它不可以返回相应的响应作为对其他请求的回复，除非出现以下任一例外情况：

 

  1. 如果响应包含"s-maxage"缓存控制指令，缓存可能使用该响应来回复后续请求。但是（如果指定的最大年龄已过）代理缓存必须使用新请求的请求头先和源服务器重新验证该响应，以允许源服务器去验证新请求。（这是s-maxage定义的行为。）如果响应包含"s-maxage=0"，代理在重复使用该响应之前必须总是进行重新验证。

 

  2. 如果响应包含"must-revalidate"缓存控制指令，缓存可能使用该响应来回复后续请求。但是如果该响应已经过时，所有的缓存必须使用新请求的请求头先和源服务器重新验证该响应，以允许源服务器验证新请求。

 

  3. 如果响应包含"public"缓存控制指令，该响应可能返回用来回复后续请求。

 

14.9 Cache-Control

Cache-Control通用头字段用于指定请求/响应链上所有缓存机制必须遵守的指令。指令指定旨在防止缓存对请求或响应产生不利干扰的行为。 这些指令通常覆盖默认的缓存算法。 缓存指令是单向的，因为请求中存在指令并不意味着响应中将给出相同的指令。

 

  注意，HTTP/1.0缓存可能实现Cache-Control并且可能只实现Pragma: no-cache（参考14.32章节）。

 

代理或者网关应用程序必须传递缓存指令，无论它们对该应用程序的意义如何，因为该指令可能适用于请求/响应链上的所有接收者。 不可能为特定缓存指定缓存命令。

 

    Cache-Control = "Cache-Control" ":" 1#cache-directive

 

  cache-directive = cache-request-directive

         | cache-response-directive

 

  cache-request-directive =

           "no-cache"                          ; Section 14.9.1

         | "no-store"                          ; Section 14.9.2

         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4

         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3

         | "min-fresh" "=" delta-seconds       ; Section 14.9.3

         | "no-transform"                      ; Section 14.9.5

         | "only-if-cached"                    ; Section 14.9.4

         | cache-extension                     ; Section 14.9.6

 

  cache-response-directive =

           "public"                               ; Section 14.9.1

         | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1

         | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1

         | "no-store"                             ; Section 14.9.2

         | "no-transform"                         ; Section 14.9.5

         | "must-revalidate"                      ; Section 14.9.4

         | "proxy-revalidate"                     ; Section 14.9.4

         | "max-age" "=" delta-seconds            ; Section 14.9.3

         | "s-maxage" "=" delta-seconds           ; Section 14.9.3

         | cache-extension                        ; Section 14.9.6

 

  cache-extension = token [ "=" ( token | quoted-string ) ]

 

14.9.1 什么是”可缓存的“ 

默认情况下，如果是某个请求方式，请求头部字段，以及响应状态指示它是”可缓存的“ 

要求，那么这个响应是”可缓存的“ 。第13.4 章节总结了这些默认可缓存性行为。接下来的Cache-Control指令允许源服务器覆盖响应的默认可缓存性行为：

public 

表示响应可能被任何缓存系统缓存，即使它在正常情况下是不可缓存的或仅在non-shared缓存中才是可缓存的。(更多详细信息可参考第14.8 章节的Authorization头部字段)

 

private 

 

no-cache 

 

 

备注：大部分的HTTP/1.0缓存并不识别或服从这个指令。

 

 

14.9.2 缓存可能会存储什么东西

 

no-store 

no-store指令的目的是为了防止无意中被公开泄露或者保留了敏感信息(例如，备份磁盘)。no-store指令应用于整个消息，并且可能[MAY]在请求或响应消息中被发送。如果在请求消息中被发送，缓存不会存储[MUST NOT store]这个请求消息或者这个请求消息的任何响应的任何部分。如果在响应消息中被发送，缓存不会存储[MUST NOT store]这个响应或者引起这个响应的请求的任何部分。这个指令应用于non- shared及shared 缓存。这个环境下的” MUST NOT store “意味着缓存不能有意的在非易失性的存储介质中存储信息，并且在转发它之后必须尽可能及时做最大努力试图从易失性的存储介质中删除信息。

 

即使当这个指令关联一个响应时，用户可能在缓存系统之外(例如，通过”另存为 “对话框)显式的存储这样的响应。历史缓冲区可能会存储这些响应作为其正常操作的一部分。 

 

 

 

 

14.9.3 基本失效机制的限制

14.9.4 缓存重新验证和重新加载控制

14.9.5 No-Transform指令

14.9.6 缓存控制扩展

 

14.10 Connection 

 

 

 

14.11 Content-Encoding 

14.12 Content-Language 

14.13 Content-Length 

 

 

 

 

14.14 Content-Location 

14.15 Content-MD5 

    Content-MD5   = "Content-MD5" ":" md5-digest

 

    md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>

14.16 Content-Range 

14.17 Content-Type 

14.18 Date 

Date通用头部表示消息产生的日期和时间，和RFC 822中的orig-date的语义相同。该字段值是一个HTTP-date，它必须以RFC 1123 [8]-日期格式发送。

 

Date = "Date" ":" HTTP-date

例如：

Date: Tue, 15 Nov 1994 08:12:31 GMT

 

源服务器必须在所有响应中包含Date头部字段，以下情况除外：

 

14.18.1 无时钟的源服务器操作

14.19 ETag 

 

 

 

14.20 Expect 

14.21 Expires 

Expires实体头部（entity-header）字段给定了响应被认为过时的日期/时间。过期的缓存条目通常可能不会由缓存（cache，或者缓存代理，或者用户代理缓存）返回，除非它首先由原始服务器（或者拥有该实体新副本的中间缓存）经过验证。参考13.2章节的过期模型的未来讨论。

 

Expires字段的存在并不意味着原始服务器会在该时间之前或之后改变或者终止已经存在的值。

 

格式是3.3.1章节中HTTP-Date定义的一个绝对日期和时间；它必须是RFC 1123中的日期格式：

 

    Expires = "Expires" ":" HTTP-date

 

一个使用例子是

 

    Expires: Thu, 01 Dec 1994 16:00:00 GMT

 

    注意：如果响应包含带有max-age指令（参考14.9.3章节）的Cache-Control字段，则该指令将覆盖Expires字段。

 

HTTP/1.1客户端和缓存必须将其他无效的日期格式，特别是包含"0"值，处理为过去时间（例如， “already expired”）。

 

为了将一个响应标记为"already expired,"，原始服务器发送一个和Date头部一样的Expires日期。参考13.2.4章节中的过期计算规则

 

为了将一个响应标记为"never expires,"，原始服务器发送一个距离响应发送时间差不多1年的Expires日期。HTTP/1.1服务器不应该发送大于未来1年的Expires日期。

 

默认不可缓存的响应，存在Expires头部字段的日期值在将来的某个时间内表示响应是可缓存的，除非Cache-Control头部字段（第14.9节)另有指示。

 

14.22 From 

From请求头字段，如果指定了，应该包含一个控制请求用户代理的用户互联网e-mail地址，这个地址应该是机器可用的，这个在RFC 822 [9]（RFC 1123 [8]更新过）中"mailbox"定义。

 

    From = "From" ":" mailbox

 

一个例子：

 

From: [e-mail]

 

这个头字段可能用于日志记录目的，用作识别无效的或不希望的请求来源。它不应该用于不安全的访问保护形式。对这个字段的解释是，指定人代为执行请求，他对所执行的方式承担责任。特别的，机器人代理应该包含这个头部，以便接收端出现问题时可以联系负责运行机器人的人。

 

这个字段的互联网email地址可能和发起请求的互联网主机分开。例如，当请求通过代理传递时，应该使用原始发起者的地址。

 

未经用户批准，客户端不应该发送From头部字段，因为它可能和用户的隐私利益，或者其站点安全策略产生冲突。强烈建议用户在请求之前任何时间能够禁用、启用以及修改这个字段的值。

 

14.23 Host 

Host请求头字段指定所请求资源的互联网host和port，从用户或者引用资源（通常是一个HTTP URL，在3.2.2章中有描述）给定的原始URI获得。Host字段值必须表示原始URL给定的原始服务器或网关命名机构。这允许原始服务器或网关区分内部歧义URL，例如在一个IP地址上多主机名的服务器根URL "/"

 

Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

 

"host"后面没跟端口信息表示请求服务的默认端口（例如，对于HTTP URL，则为"80"）。例如，请求原始服务器<http://www.w3.org/pub/WWW/>将正确的包含：

 

    GET /pub/WWW/ HTTP/1.1

    Host: www.w3.org

 

在HTTP/1.1请求中，客户端必须在请求消息中包含Host头部字段。如果请求的URI不包含请求服务的主机名，Host请求必须指定一个空值。HTTP/1.1代理必须保证转发的任何消息包含一个合适的Host头部以标识代理请求的服务。所有基于HTTP/1.1的服务器必须返回400 (Bad Request)错误，如果HTTP/1.1请求消息中缺少Host头部。

 

14.24 If-Match 

 

 

 

 

If-Unmodified-Since 

14.25 If-Modified-Since 

14.26 If-None-Match 

14.27 If-Range 

14.28 If-Unmodified-Since 

14.29 Last-Modified 

 

 

 

 

14.30 Location 

14.31 Max-Forwards 

14.32 Pragma

 

Pragma = "Pragma" ":" 1#pragma-directive 

 

pragma-directive = "no-cache" | extension-pragma 

 

extension-pragma = token [ "=" ( token | quoted-string ) ] 

 

14.33 Proxy-Authenticate 

14.34 Proxy-Authorization

 

 

 

 

 

14.35 Range 

14.35.1 字节范围 

14.35.2 范围检索请求 

14.36 Referer 

14.37 Retry-After 

14.38 Server 

 

 

 

 

 

14.39 TE 

TE请求头字段指定将在响应接受什么扩展传输编码，以及在分块传输编码中是否将接受Trailer字段。它的值可能由"trailers"关键字和/或逗号分割的带可选接收参数的扩展传输编码名列表（如第3.6章节中描述）。

 

    TE        = "TE" ":" #( t-codings )

    t-codings = "trailers" | ( transfer-extension [ accept-params ] )

 

出现"trailers"关键字表示客户端将在分块传输编码中接受Trailer字段，如第3.6.1章节定义。这个关键字和transfer-coding值一起保留使用，尽管这个关键字自己不表示transfer-coding。

 

它的使用例子：

    TE: deflate

    TE:

    TE: trailers, deflate;q=0.5

 

TE头字段只应用于立即连接。因此，每当HTTP/1.1消息中存在TE时，必须在连接头字段（第14.10节）中提供关键字。

 

服务器根据TE字段检查transfer-coding是否接受，使用这些规则：

 

    1. 传输编码"chunked"总是一定是可接受的。如果"trailers"关键字被列出，客户端表示将代表自己和任何下游客户端在分块响应中接受Trailer字段。其含义是，如果给出，客户端声明，要么所有下游客户端都愿意接受转发响应中的Trailer字段，要么它将试图代表下游接收者缓冲响应。

 

    备注：HTTP/1.1不定义任何限制分块响应大小的方法，这样客户端就可以保证缓冲这个响应。

 

    2. 如果检查到传输编码是TE字段中列出的传输编码中的一个，那么就是可接受的。除非，它伴随着Q值为0。 (如第3.9节所定义，q值为0表示“不可接受。 “)

 

    3. 如果多个传输编码都是可接受的，那么Q值不为0且最高的那个优先为可接受的传输编码。"chunked"传输编码的Q值总是1。

 

如果TE字段值为空或者没有TE字段，传输编码只能是"chunked"。没有传输编码的消息总是能被接受的。

 

14.40 Trailer

Trailer通用字段值表示给定的一组头字段，这组头字段存在于用块传输编码的消息的trailer中。

 

    Trailer  = "Trailer" ":" 1#field-name

 

HTTP/1.1消息应该在一个带非空trailer的使用分快传输编码的消息中包含一个Trailer头字段。这么做允许接收者知道期望哪个头字段在trailer中。

 

如果没有出现Trailer头字段，trailer不应该包含任何头字段。有关在"chunked"传输编码中使用trailer字段的限制，请参见第3.6.1节。

 

Trailer头字段中列出的消息头字段不包含以下头字段：

 

    . Transfer-Encoding

 

    . Content-Length

 

    . Trailer

 

14.41 Transfer-Encoding

Transfer-Encoding通用头字段表示为了在发送者和接收者之间安全的传输消息体，什么类型的转换被应用于消息体。这与内容编码不同，因为传输编码是消息的属性，而不是实体的属性。

 

    Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

 

传输编码在第3.6章节中定义。一个例子是：

 

    Transfer-Encoding: chunked

 

如果多个编码被应用于一个entity，传输编码必须按照它们应用的顺序列出来。关于编码参数的额外信息可能通过本规范没有定义的其他实体头字段提供。

 

许多老HTTP/1.0应用不识别Transfer-Encoding头。

 

14.42 Upgrade 

14.43 User-Agent 

14.44 Vary 

 

 

 

 

14.45 Via 

14.46 Warning 

14.47 WWW-Authenticate  

 

15 安全考虑

15.1 隐私

15.1.1 服务器日志信息的滥用

15.1.2 敏感信息传输

15.1.3 URI中敏感信息编码

15.1.4 Accept头相关的隐私问题

15.2 基于文件和路径名的攻击

15.3 DNS欺骗

15.4 Location头和欺骗

15.5 Content-Disposition问题

15.6 认证凭证和空闲客户端

15.7 代理和缓存

15.7.1 代理上的拒绝服务攻击

16 致谢

17 引用

   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC

       1766, March 1995.

 

   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,

       D. and B. Alberti, "The Internet Gopher Protocol (a distributed

       document search and retrieval protocol)", RFC 1436, March 1993.

 

   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC

       1630, June 1994.

 

   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource

       Locators (URL)", RFC 1738, December 1994.

 

   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -

       2.0", RFC 1866, November 1995.

 

   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer

       Protocol -- HTTP/1.0", RFC 1945, May 1996.

 

   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

       Extensions (MIME) Part One: Format of Internet Message Bodies",

       RFC 2045, November 1996.

 

   [8] Braden, R., "Requirements for Internet Hosts -- Communication

       Layers", STD 3, RFC 1123, October 1989.

 

   [9] Crocker, D., "Standard for The Format of ARPA Internet Text

       Messages", STD 11, RFC 822, August 1982.

 

   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,

        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype

        Functional Specification," (v1.5), Thinking Machines

        Corporation, April 1990.

 

   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,

        June 1995.

 

   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET

        Messages", RFC 1036, December 1987.

 

   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC

        977, February 1986.

 

   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part

        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,

        November 1996.

 

   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC

        1867, November 1995.

 

   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,

        August 1982.

 

   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,

        November 1996.

 

   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC

        959, October 1985.

 

   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,

        October 1994.

 

   [20] Sollins, K. and L. Masinter, "Functional Requirements for

        Uniform Resource Names", RFC 1737, December 1994.

 

   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for

        Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.

 

   [22] ISO-8859. International Standard -- Information Processing --

        8-bit Single-Byte Coded Graphic Character Sets --

        Part 1: Latin alphabet No. 1, ISO-8859-1:1987.

        Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.

        Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.

        Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.

        Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.

        Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.

        Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.

        Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.

        Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.

 

   [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC

        1864, October 1995.

 

   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC

        1900, February 1996.

 

   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC

        1952, May 1996.

 

   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP

        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,

        Dec. 1995. Slightly revised version of paper in Proc. 2nd

        International WWW Conference '94: Mosaic and the Web, Oct. 1994,

        which is available at

        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat

        ency.html.

 

   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP

        Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,

        ISI Research Report ISI/RR-98-463, (original report dated Aug.

        1996), USC/Information Sciences Institute, August 1998.

 

   [28] Mills, D., "Network Time Protocol (Version 3) Specification,

        Implementation and Analysis", RFC 1305, March 1992.

 

   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification

        version 1.3", RFC 1951, May 1996.

 

   [30] S. Spero, "Analysis of HTTP Performance Problems,"

        http://sunsite.unc.edu/mdma-release/http-prob.html.

 

   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format

        Specification version 3.3", RFC 1950, May 1996.

 

   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,

        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:

        Digest Access Authentication", RFC 2069, January 1997.

 

   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.

        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC

        2068, January 1997.

 

   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement

        Levels", BCP 14, RFC 2119, March 1997.

 

   [35] Troost, R. and Dorner, S., "Communicating Presentation

        Information in Internet Messages: The Content-Disposition

        Header", RFC 1806, June 1995.

 

   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and

        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.

        [jg639]

 

   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February

        1997. [jg640]

 

   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and

        ISO-10646", RFC 2279, January 1998. [jg641]

 

   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,

        Lie, H., and C. Lilley. "Network Performance Effects of

        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes

        France, September 1997.[jg642]

 

   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part Two: Media Types", RFC 2046, November

        1996. [jg643]

 

   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",

        BCP 18, RFC 2277, January 1998. [jg644]

 

   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource

        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,

        August 1998. [jg645]

 

   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,

        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP

        Authentication: Basic and Digest Access Authentication", RFC

        2617, June 1999. [jg646]

 

   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy

        servers," Work in Progress. [jg647]

 

   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of

        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March

        1997.

 

   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP

        9, RFC 2026, October 1996.

 

   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol

        (HTCPCP/1.0)", RFC 2324, 1 April 1998.

 

   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part Five: Conformance Criteria and Examples",

        RFC 2049, November 1996.

 

   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation

        Information in Internet Messages: The Content-Disposition Header

        Field", RFC 2183, August 1997.

 

18 作者的联系地址

19 附录

19.1 互联网媒体类型message/http和application/http

19.2 互联网媒体类型multipart/byteranges

19.3 极限应用

19.4 HTTP实体和RFC2045实体之间的差异

19.4.1 MIME-Version

19.4.2 转换为规范形式

19.4.3 日期格式转换

19.4.4 Content-Encoding介绍

19.4.5 无Content-Transfer-Encoding

19.4.6 Transfer-Encoding介绍

19.4.7 MHTML和行长度限制

19.5 附加功能

19.5.1 Content-Disposition

19.6 和以前版本的兼容性

19.6.1 HTTP/1.0中的更新

19.6.2 和HTTP/1.0持久连接的兼容性

19.6.3 RFC 2068中的更新

本规范经过仔细审核，以纠正和消除关键词使用的歧义；RFC2068在RFC2119[34]规定的公约方面存在许多问题。

 

澄清哪些错误代码应该用于入站服务器故障(例如。 DNS故障)。（第10.5.5节）。

 

当一个资源第一次被创建的时候，CREATE要求发送一个Etag。

 

Content-Base已经从规范中删除。它没有得到广泛的实施，没有一个强大的扩展机制，也没有简单、安全的方法来引入它。此外，它在MHTML[45]中以类似但不相同的方式使用。

 

Transfer-coding和消息长度的交互方式在使用块化编码时需要进行精确的修复（以允许不能自我分隔的传输编码）；重要的是要准确地确定如何计算消息长度。（第3.6、4.4、7.2.2、13.5.2、14.13、14.16节）

 

为了解决缓存中发现的问题，引入了"identity" content-coding（第3.5节）

 

质量值0应该表明"I don't want something"，以允许客户端拒绝表示。（第3.9章节）

 

HTTP版本号的使用和解释已由RFC2145澄清。 要求代理将请求升级到他们支持的最高协议版本，以处理HTTP/1.0实现中发现的问题（3.1节）

 

为了避免在Accept头中出现字符集名称的爆炸，引入了字符集通配。 （第14.2节）

 

在HTTP/1.1的Cache-Control模型中漏掉了一个案例；引入了s-maxage来添加这个缺失的案例。 （第13.4、14.8、14.9、14.9.3节）

 

响应中Cache-Control的max-age指令没有被正确定义。（第14.9.3章节）

 

在某些情况下，服务器（特别是代理）不知道响应的完整长度，但能服务byterange请求。因此我们需要一种机制，以允许content-range的byterange，不指定消息的完整长度。（第14.16章节）

 

如果总是返回所有元数据，range请求响应将变得非常冗长；通过允许服务器在206响应中只发送需要的头，可以避免这个问题。（第10.2.7，13.5.3和14.27章节）

 

修复不能满足条件的range请求的问题；有两种情况：语法问题，以及文档中不存在range。需要416状态码来解决这个针对byte range请求的本不是文档实际内容错误而需要提示一个错误的歧义。（第10.4.17，14.16章节）

 

重写消息传输要求，使实现者更难出错，因为这里的错误后果会对互联网产生重大影响，并处理以下问题：

 

    1. 修改"HTTP/1.1或者以后的版本"为"HTTP/1.1"，在这种情况下，对HTTP/1.x的未来版本的实现的行为提出了要求

 

    2. 明确表示用户代理应该重试请求，通常不是“客户端"。

 

    3. 将客户端忽略不符合预期的100（Continue）响应和代理转发的100响应的需求转换为1xx的一般响应。

 

    4. 修改了一些特定于TCP的语言，以更清楚地表明非TCP传输对于HTTP是可能的。

 

    5. 在源服务器发送一个必要的100（Continue）响应之前，要求源服务器不要等待请求体

 

    6. 如果服务器已经接收了部分请求体，允许服务器（但非必须）漏掉100（Continue）。

 

    7. 允许服务器防御拒绝服务攻击（DOS攻击）和坏客户端。

 

这个更新添加了Expert头和417状态码。消息传输需求修复在8.2，10.4.18，8.1.2.2，13.11以及14.20章节中。

 

代理应该能够在适当的时候添加Content-Length。（第13.5.2章节）

 

消除403和404响应之间的混淆。 （第10.4.4、10.4.5和10.4.11节）

 

告警信息可能被错误的缓存，或者没有适当的更新。（第13.1.2，13.2.4，13.5.2，13.5.3，14.9.3以及14.46）Warning也必须是个通用头，因为PUT或者其他方法在请求中可能有要求。

 

Transfer-coding存在重要问题，特别是和分快编码的交互中。解决方案是，传输编码成为和内容编码一样完整成熟的编码。 这包括为传输编码添加一个IANA注册中心（与内容编码分开），一个新的头字段(TE)以及将来启用Trailer头。 传输编码是一个主要的性能效益，因此它值得修复[39]。 TE还解决了由于认证跟踪者、块编码和HTTP/1.0客户端之间的交互而可能出现的另一个模糊的向下互操作性问题。 （第3.6、3.6.1和14.39节）

 

定义了PATCH，LINK，UNLINK方法，但在此规范的之前版本中，通常没被实现。参考RFC 2068[33]。

 

此规范的之前版本定义了Alternates, Content-Version, Derived-From, Link, URI, Public以及Content-Base头字段，但通常没被实现。参考RFC 2068 [33]。

 

20 索引

索引请参考此RFC的PostScript版本。

 

21 完整版权声明

写道

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

各大网站使用的web服务器

www.taobao.com Tengine 

www.tmall.com Tengine 

ju.taobao.com Tengine 

www.alibaba.com Apache-Coyote/1.1 

www.koubei.com Tengine 

www.1688.com Tengine 

www.jd.com jdws

www.amazon.com  Server 

www.amazon.cn Server 

www.yhd.com Apache-Coyote/1.1

www.kaola.com nginx 

www.mogujie.com JuanNiuX/12.8.12 

www.vip.com vipshop/Vbia 

www.suning.com nginx 

www.gome.com.cn GOMEWS 

www.dangdang.com nginx/1.2.5 

www.jumei.com JUMEI 

www.vancl.com Microsoft-IIS/7.5 

www.moonbasa.com DnionOS/1.2.1.16 

www.weidian.com nginx 

www.etao.com Tengine 

www.blemall.com nginx 

www.yixun.com nginx

各大网站使用的web服务器

www.dianping.com DPweb 

www.meituan.com Tengine 

www.ele.me Qnginx/1.1.1 

www.nuomi.com Apache 

www.sina.com.cn nginx 

www.163.com openresty 

www.sohu.com SWS 

www.qq.com squid/3.4.3 这个有点怪，squid?

www.360.com 360wzws 

www.sougou.com Apache 

www.alipay.com Tengine/2.1.0 

www.lu.com LWS/1.1 

qzone.qq.com X2S_Platform 

www.126.com nginx 

mail.qq.com nginx 

t.qq.com nginx/1.9.5 

weibo.com WeiBo 

www.baidu.com bfe/1.0.8.14 

www.youku.com openresty 

www.iqiyi.com Apache 1.3.29 

www.tudou.com Tengine/1.5.0 

www.le.com nginx 

www.pps.tv QWS 

www.kankan.com nginx/1.2.2 

www.pptv.com ApacheTrafficServer/4.2.3 

www.alitrip.com Tengine 

 

 

http://www.ietf.org/rfc/rfc2616.txt 

https://tools.ietf.org/html/rfc2616

http://www.ietf.org/rfc/rfc2068.txt 

http://www.ietf.org/rfc/rfc1945.txt