http

HTTP

 

介绍

符号约定和通用语法 

协议参数

HTTP消息

请求

响应

实体

连接

请求方式

响应状态

访问认证

内容协商

HTTP中的缓存

头部字段

安全考虑

感谢 

引用

作者联系方式

附录 

索引

版权声明 

介绍

符号约定和通用语法

协议参数

HTTP版本

统一资源定位符

通用语法

HTTP URL

URI比较

日期/时间格式

完整日期

Delta Seconds 

字符集

无法处理的字符集

内容编码

传输编码

分块传输编码

媒介类型

标准化及缺省文本

Multipart类型

产品标识 

质量值 

语言标签 

实体标签 

Range单位

 

HTTP版本

HTTP使用一种“<主版本号>.<小版本号>”(“<major>.<minor>”)的版本方式来表示协议的版本。协议的这种版本策略目的并不是获得通信中的特征支持，而是允许发送者指定消息格式以及理解HTTP通信的能力。

 

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

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

 

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

 

 

统一资源定位符

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

 

 

 

 

统一资源定位符

通用语法

HTTP中的统一资源定位符可以表示为绝对格式或者有个基准，根据所使用的上下文，基于这个基准而表示的相对格式。这两种格式辨别的依据就是绝对格式总是由一个协议“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”的约定。

 

 

 

请求

 

 

 

 

 

 

 

 

 

 

实体

实体头部字段

实体包体

类型

实体长度

 

 

 

实体头部字段

实体包体

类型

当实体包体包含了一条消息，包体的消息数据类型由头部字段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“类型。

 

实体长度

 

 

 

 

 

请求方式

安全且幂等的方式

安全的方式

幂等的方式

OPTIONS 

GET 

HEAD 

POST 

PUT 

DELETE 

TRACE 

CONNECT 

 

请求方式

在RFC 1945 HTTP/1.0规范中只定义GET、HEAD、POST三种请求方式。

 

HTTP/1.1实际上存在这两个版本：RFC 2068以及加强的HTTP/1.1 RFC 2616。

 

RFC 2068 HTTP/1.1在RFC 1945 HTTP/1.0的基础上新增了OPTIONS、PUT 、DELETE、TRACE这几种请求方式。

 

RFC 2616 HTTP/1.1在RFC 2068 HTTP/1.1的基础上新增了CONNECT这个请求方式。 RFC 2616 HTTP/1.1总共定义了8中请求方式。

 

 

安全且幂等的方式

安全的方式

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

幂等的方式

 

 

 

 

OPTIONS

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章节。 

 

 

 

HEAD

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

 

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

 

 

 

 

POST

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

已存在的资源的注解

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

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

通过追加操作扩展数据库  

 

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

 

 

 

 

 

 

 

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)的响应；然后用户代理可能就”是否重定向请求“，作出自己的决定。

 

PUT

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

 

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

 

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

 

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

 

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

 

 

 

 

 

DELETE

TRACE

CONNECT

响应状态

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

100 Continue 

101 Switching Protocols 

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

200 OK 

201 Created 

202 Accepted 

203 Non-Authoritative Information 

204 No Content 

205 Reset Content 

206 Partial Content 

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

300 Multiple Choices 

301 Moved Permanently 

302 Found 

303 See Other 

304 Not Modified 

305 Use Proxy 

306 (Unused) 

307 Temporary Redirect  

响应状态

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

400 Bad Request 

401 Unauthorized 

402 Payment Required 

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 Request Entity Too Large 

414 Request-URI Too Long 

415 Unsupported Media Type 

416 Requested Range Not Satisfiable 

417 Expectation Failed 

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

500 Internal Server Error 

501 Not Implemented 

502 Bad Gateway 

503 Service Unavailable 

504 Gateway Timeout 

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响应一样。

 

 

 

 

 

 

头部字段

Accept 

Accept-Charset 

Accept-Encoding 

Accept-Language 

Accept-Ranges 

Age 

Allow 

Authorization 

Cache-Control 

什么是”可缓存的“ 

什么东西可能被缓存存储

基本失效机制的限制

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

No-Transform指令

缓存控制扩展

头部字段

Connection 

Content-Encoding 

Content-Language 

Content-Length 

Content-Location 

Content-MD5 

Content-Range 

Content-Type 

Date 

无时钟的源服务器操作

ETag 

头部字段

Expect 

Expires 

From 

Host 

If-Match 

If-Modified-Since 

If-None-Match 

If-Range 

If-Unmodified-Since 

Last-Modified 

Location 

Max-Forwards 

Pragma 

Proxy-Authenticate 

Proxy-Authorization

头部字段

Range 

字节范围 

范围请求 

Referer 

Retry-After 

Server 

TE 

Trailer 

Transfer-Encoding 

Upgrade 

User-Agent 

Vary 

Via 

Warning 

WWW-Authenticate  

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

例如：

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%后能够保持最好的可用性的话可以给我指定任何媒介类型。“

 

 

 

 

 

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

 

 

 

 

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

 

 

 

 

Accept-Ranges 

Age 

Allow 

Authorization 

Cache-Control 

什么是”可缓存的“ 

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

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

public 

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

 

private 

 

no-cache 

 

 

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

 

 

 

 

Cache-Control 

什么东西可能被缓存存储

no-store 

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

 

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

 

 

 

 

 

 

 

 

Cache-Control 

基本失效机制的限制

 

 

 

 

 

Cache-Control 

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

 

 

 

 

 

 

Cache-Control 

No-Transform指令

 

 

 

 

 

 

Cache-Control 

缓存控制扩展

 

 

 

 

 

Connection 

Content-Encoding 

Content-Language 

Content-Length 

Content-Location 

Content-MD5 

Content-Range 

Content-Type 

Date 

ETag 

Expect 

Expires 

From 

Host 

If-Match 

If-Modified-Since 

If-None-Match 

If-Range 

If-Unmodified-Since 

Last-Modified 

Location 

Max-Forwards 

Pragma 

 

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

 

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

 

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

 

 

 

 

 

 

 

Proxy-Authenticate 

Proxy-Authorization 

Range 

Referer 

Retry-After 

Server 

TE 

Trailer 

Transfer-Encoding 

Upgrade 

User-Agent 

Vary 

Via 

Warning 

WWW-Authenticate 

各大网站使用的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 

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

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