HTTP协议-最新RFC文档-中文版
http协议详解(超详细)

http协议详解(超详细)1. 基础概念篇1.1 介绍HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写。
它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本。
其中最著名的就是RFC 2616。
RFC 2616定义了今天普遍使用的一个版本——HTTP 1. 1。
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。
它可以使浏览器更加高效,使网络传输减少。
它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
HTTP是一个应用层协议,由请求和响应构成,是一个标准的客户端服务器模型。
HTTP是一个无状态的协议。
1.2 在TCP/IP协议栈中的位置HTTP协议通常承载于TCP协议之上,有时也承载于TLS或SSL协议层之上,这个时候,就成了我们常说的HTTPS。
如下图所示:默认HTTP的端口号为80,HTTPS的端口号为443。
1.3 HTTP的请求响应模型HTTP协议永远都是客户端发起请求,服务器回送响应。
见下图:这样就限制了使用HTTP协议,无法实现在客户端没有发起请求的时候,服务器将消息推送给客户端。
HTTP协议是一个无状态的协议,同一个客户端的这次请求和上次请求是没有对应关系。
1.4 工作流程一次HTTP操作称为一个事务,其工作过程可分为四步:1)首先客户机与服务器需要建立连接。
只要单击某个超级链接,HTTP的工作开始。
2)建立连接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(UR L)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
(完整word版)Http协议解说

Http协议:超文本传输协议浏览器与服务端之间传输数据的协议,底层的传输协议为TCP。
Http则为应用层协议,负责定义传输数据的格式HTTP协议分为1.0与1.1两个版本。
现在常用为1.1版本。
协议规定客户端与服务端通讯方式为:一次请求一次响应,即:客户端发起请求,服务端接收到请求后向客户端发送响应。
服务端不会主动发送内容给客户端。
采取“一问一答”的形式HTTP 请求和响应分别定义了个格式。
并且,无论是请求还是响应中发送的字符(不含正文部分内容)都只能符合ISO8859-1编码字符(如:数字,字母,符号).像中文等其它字符都需要经过处理后才可以发送。
HTTP请求格式:一个HTTP请求分为三部分组成:请求行,消息头,消息正文1:<请求行>请求行分为三部分:请求方法资源路径协议(CRLF)method(请求方法)url(资源路径) protocol(CRLF)例如:GET /index.html HTTP/1.1(CRLF)请求行以CRLF结束(回车加换行)CR:回车符,asc编码中对应数字13LF:换行符,asc编码中对应数字102.<消息头>消息头由若干行表示,每行表示一个具体的头信息,每个头信息式分为两部分:消息头名字:消息头的值(CRLF)name: value(CRLF)每个消息头都以CRLF结尾。
最后一个消息头结尾处会有两个CRLF,第一个表示最后一个消息头结束,第二个表示消息头(整个)部分结束。
例如:Host: www.localhost:8080(CRLF)Connection: keep-alive(CRLF)Cache-Control: max-age=0(CRLF)Upgrade-Insecure-Requests: 1(CRLF)User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/58.0.3029.110 Safari/537.36(CRLF)Accept:text/html,application/xhtml+xml,application/xml;q=0.9,im age/webp,*/*;q=0.8(CRLF)Accept-Encoding: gzip, deflate, sdch, br(CRLF)Accept-Language: zh-CN,zh;q=0.8(CRLF)(CRLF)3.<消息正文>正文部分不是必须部分,消息正文是2进制数据。
RFC2617 中文版

1.备忘 (3)2.版权申明 (3)3.摘要 (3)4.授权鉴别 (4)4.1.对HTTP/1.1规范的依赖 (4)4.2.访问鉴别框架 (4)5.基本鉴别方案 (6)6.摘要访问鉴别方案 (8)6.1.介绍 (8)6.1.1.目的 (8)6.1.2.操作概述 (8)6.1.3.摘要值的表示 (8)6.1.4.该方案的局限性 (8)6.2.摘要报头的规范 (9)6.2.1.WWW-Authenticate响应报头 (9)6.2.2.Authorization请求报头 (11)6.2.3.Authentication-info报头 (15)6.3.摘要操作 (17)6.4.安全协议讨论 (17)6.5.例子 (18)6.6.代理鉴别和代理授权 (18)7.安全考虑 (20)7.1.客户使用基本鉴别 (20)7.2.客户使用摘要鉴别 (20)7.3.受限的NONCE值使用 (21)7.4.基本鉴别与摘要鉴别的比较 (21)7.5.回放式攻击 (22)7.6.多方鉴别方案产生的缺点 (22)7.7.在线字典攻击 (23)7.8.中间人 (23)7.9.选择纯文本攻击 (23)7.10.预先计算的字典攻击 (24)7.11.批处理方式暴力攻击 (24)7.12.假冒服务器欺骗 (24)7.13.存储口令 (24)7.14.总结 (25)8.例子实现 (26)9.参考书目 (30)10.作者地址 (30)11.完整版权申明 (30)12.致谢 (30)1.备忘本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。
详情请参见官方文件(STD1)。
本文可任意分发。
2.版权申明Copyright (C) The Internet Society (1999). All Rights Reserved3.摘要“HTTP/1.0”中包括基本访问鉴别方案(Basic Access Authentication scheme)。
RFC2616 中文文档

Network Working Group(网络工作组) R. FieldingRequest for Comments: 2616 UC IrvineObsoletes(过时弃用): 2068 J. GettysCategory: Standards Track (类别:标准组)Compaq/W3CJ. MogulCompaqH. FrystykW3C/MITL. MasinterXeroxP. LeachMicrosoftT. Berners-LeeW3C/MITJune 1999超文本传输协议-HTTP/1.1本备忘录状况本文档说明了用于互联网社区的标准化跟踪协议,但还需要讨论和建议以便更加完善。
请参考"互联网官方协议标准"(STD1)来了解本协议的标准化状态。
分发散布本文是不受限制的。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.摘要超文本传输协议(HTTP)是一种应用于分布式、协作式、超媒体信息系统的应用层协议。
它是一种通用的,状态无关的协议,可以用于除了超文本以外,还可以通过扩展它的请求方法,错误代码和报头[47]来完成更多任务,比如名称服务和分布对象管理系统。
HTTP的一个特点是数据表示方式的典型性(typing)和可协商性,允许建立独立于被传输数据的系统。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。
本规范定义了HTTP/ 1.1协议,这是RFC 2068的升级版[33]。
[页码1]------------------------------------------------------------------------目录1 Introduction (介绍) (7)1.1 Purpose(目的) (7)1.2 Requirements (要求) (8)1.3 Terminology (术语) (8)1.4 Overall Operation (概述) (12)2 Notational Conventions and Generic Grammar(标志转换及通用语法) (14)2.1 Augmented BNF (扩充的范式) (14)2.2 Basic Rules (基本规则) (15)3 Protocol Parameters (协议参数) (17)3.1 HTTP Version (版本) (17)3.2 Uniform Resource Identifiers (统一资源标识) (18)3.2.1 General Syntax (通用语法) (19)3.2.2 http URL (19)3.2.3 URI Comparison (URI对比) (20)3.3 Date/Time Formats (时间日期格式) (20)3.3.1 Full Date (完整日期) (20)3.3.2 Delta Seconds (21)3.4 Character Sets (字符集) (21)3.4.1 Missing Charset (不见了的字符集) (22)3.5 Content Codings (内容编码) (23)3.6 Transfer Codings (传输编码) (24)3.6.1 Chunked Transfer Coding (大块数据传输编码) (25)3.7 Media Types (媒介类型) (26)3.7.1 Canonicalization and Text Defaults (27)3.7.2 Multipart Types (复合类型) (27)3.8 Product Tokens (产品记号) (28)3.9 Quality Values (质量值) (29)3.10 Language Tags (语言标签) (29)3.11 Entity Tags (实体标签) (30)3.12 Range Units (范围单位) (30)4 HTTP Message (HTTP 消息) (31)4.1 Message Types (消息类型) (31)4.2 Message Headers (消息头) (31)4.3 Message Body (消息主体) (32)4.4 Message Length (消息长度) (33)4.5 General Header Fields (通用头字段) (34)5 Request (请求) (35)5.1 Request-Line (请求行) (35)5.1.1 Method (方法) (36)5.1.2 Request-URI (请求-URI) (36)5.2 The Resource Identified by a Request (38)5.3 Request Header Fields (请求头字段) (38)6 Response (应答) (39)6.1 Status-Line (状态行) (39)6.1.1 Status Code and Reason Phrase (状态码和原因短语) (39)6.2 Response Header Fields (应答头字段) (41)[页码2]------------------------------------------------------------------------7 Entity (实体) (42)7.1 Entity Header Fields (实体头字段) (42)7.2 Entity Body (实体主体) (43)7.2.1 Type (类型) (43)7.2.2 Entity Length (实体长度) (43)8 Connections (连接) (44)8.1 Persistent Connections (持久连接) (44)8.1.1 Purpose (目的) (44)8.1.2 Overall Operation(概述) (45)8.1.3 Proxy Servers (代理服务器) (46)8.1.4 Practical Considerations (实践中的考虑) (46)8.2 Message Transmission Requirements (消息传送请求) (47)8.2.1 Persistent Connections and Flow Control(持久连接和流程控制) (47)8.2.2 Monitoring Connections for Error Status Messages(出错状态消息的监测连接) (48)8.2.3 Use of the 100 (Continue) Status(状态号100的使用) (48)8.2.4 Client Behavior if Server Prematurely Closes Connection(如果服务器过早关闭连接,客户端的行为) (50)9 Method Definitions (方法的定义) (51)9.1 Safe and Idempotent Methods (安全和幂等方法) (51)9.1.1 Safe Methods (安全方法) (51)9.1.2 Idempotent Methods (幂等方法) (51)9.2 OPTIONS (选项) (52)9.3 GET (命令:GET) (53)9.4 HEAD (命令:HEAD) (54)9.5 POST (命令:POST) (54)9.6 PUT (命令:PUT) (55)9.7 DELETE (命令:DELETE) (56)9.8 TRACE (命令:TRACE) (56)9.9 CONNECT (命令:CONNECT) (57)10 Status Code Definitions (状态码定义) (57)10.1 Informational 1xx (报告:1XX) (57)10.1.1 100 Continue (100 继续) (58)10.1.2 101 Switching Protocols(交换协议) (58)10.2 Successful 2xx (成功:2XX) (58)10.2.1 200 OK (200 正常) (58)10.2.2 201 Created (201 已建立) (59)10.2.3 202 Accepted (202 已接受) (59)10.2.4 203 Non-Authoritative Information (无认证信息) (59)10.2.5 204 No Content (无内容) (60)10.2.6 205 Reset Content (重置内容) (60)10.2.7 206 Partial Content (部分内容) (60)10.3 Redirection 3xx (3XX 重定向) (61)10.3.1 300 Multiple Choices (复合选择) (61)10.3.2 301 Moved Permanently (永久转移) (62)10.3.3 302 Found (找到) (62)10.3.4 303 See Other (访问其他) (63)10.3.5 304 Not Modified (304 没有更改) (63)10.3.6 305 Use Proxy (305 使用代理) (64)10.3.7 306 (Unused) (306 未使用) (64)[页码3]------------------------------------------------------------------------10.3.8 307 Temporary Redirect (暂时重定向) (65)10.4 Client Error 4xx (客户端错误) (65)10.4.1 400 Bad Request (错误请求) (65)10.4.2 401 Unauthorized (未认证) (66)10.4.3 402 Payment Required (支付请求) (66)10.4.4 403 Forbidden (禁止) (66)10.4.5 404 Not Found (没有找到) (66)10.4.6 405 Method Not Allowed (方法不容许) (66)10.4.7 406 Not Acceptable (不可接受) (67)10.4.8 407 Proxy Authentication Required (要求代理认证) (67)10.4.9 408 Request Timeout (请求超时) (67)10.4.10 409 Conflict (冲突) (67)10.4.11 410 Gone (离开) (68)10.4.12 411 Length Required (长度请求) (68)10.4.13 412 Precondition Failed (预处理失败) (68)10.4.14 413 Request Entity Too Large (请求的实体太大了) (69)10.4.15 414 Request-URI Too Long (请求URI太长了) (69)10.4.16 415 Unsupported Media Type (不支持的媒提类型) (69)10.4.17 416 Requested Range Not Satisfiable (请求范围未满足) (69)10.4.18 417 Expectation Failed (期望失败) (70)10.5 Server Error 5xx (服务器错误 5XX) (70)10.5.1 500 Internal Server Error (内部错误) (70)10.5.2 501 Not Implemented (未实现) (70)10.5.3 502 Bad Gateway (错误网关) (70)10.5.4 503 Service Unavailable (服务不可用) (70)10.5.5 504 Gateway Timeout (网关超时) (71)10.5.6 505 HTTP Version Not Supported (版本不支持) (71)11 Access Authentication (访问认证) (71)12 Content Negotiation (内容协商) (71)12.1 Server-driven Negotiation (服务器驱动协商) (72)12.2 Agent-driven Negotiation (客户端驱动协商) (73)12.3 Transparent Negotiation (透明协商) (74)13 Caching in HTTP (缓存) (74)13.1.1 Cache Correctness (缓存正确性) (75)13.1.2 Warnings (警告) (76)13.1.3 Cache-control Mechanisms (缓存控制机制) (77)13.1.4 Explicit User Agent Warnings (直接用户代理警告) (78)13.1.5 Exceptions to the Rules and Warnings (规则和警告的异常).78 13.1.6 Client-controlled Behavior(客户控制的行为) (79)13.2 Expiration Model (过期模式) (79)13.2.1 Server-Specified Expiration (服务器指定过期) (79)13.2.2 Heuristic Expiration (启发式过期) (80)13.2.3 Age Calculations (年龄计算) (80)13.2.4 Expiration Calculations (过期计算) (83)13.2.5 Disambiguating Expiration Values (消除歧义的过期值) (84)13.2.6 Disambiguating Multiple Responses (消除歧义的复合应答)..84 13.3 Validation Model (确认模式) (85)13.3.1 Last-Modified Dates (最后更改日期) (86)[页码4]------------------------------------------------------------------------13.3.2 Entity Tag Cache Validators (实体标签缓存确认) (86)13.3.3 Weak and Strong Validators (强弱确认) (86)13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates当使用实体标签和最后更改日期字段时候的规则 (89)13.3.5 Non-validating Conditionals (不可确认的条件) (90)13.4 Response Cacheability (应答缓存功能) (91)13.5 Constructing Responses From Caches (从缓存构造应答) (92)13.5.1 End-to-end and Hop-by-hop Headers (端对端和逐跳的头) (92)13.5.2 Non-modifiable Headers (不可以更改的报头) (92)13.5.3 Combining Headers (组合报头) (94)13.5.4 Combining Byte Ranges (组合字节范围) (95)13.6 Caching Negotiated Responses (缓存协商过的应答) (95)13.7 Shared and Non-Shared Caches (共享和非共享缓存) (96)13.8 Errors or Incomplete Response Cache Behavior(错误或不完整应答缓存行为) (97)13.9 Side Effects of GET and HEAD (GET和HEAD的单方影响) (97)13.10 Invalidation After Updates or Deletions(更新和删除后的失效) (97)13.11 Write-Through Mandatory (强制写通过) (98)13.12 Cache Replacement (缓存替换) (99)13.13 History Lists (历史列表) (99)14 Header Field Definitions (头字段定义) (100)14.1 Accept (接受) (100)14.2 Accept-Charset (接受的字符集) (102)14.3 Accept-Encoding (接受的编码方式) (102)14.4 Accept-Language (接受的语言) (104)14.5 Accept-Ranges (接受的范围) (105)14.6 Age (年龄,生存期) (106)14.7 Allow (容许) (106)14.8 Authorization (认证) (107)14.9 Cache-Control (缓存控制) (108)14.9.1 What is Cacheable (什么可以缓存) (109)14.9.2 What May be Stored by Caches (什么将被缓存存储) (110)14.9.3 Modifications of the Basic Expiration Mechanism基本过期机制的更改 (111)14.9.4 Cache Revalidation and Reload Controls缓存重确认和重载控制 (113)14.9.5 No-Transform Directive (不可转换指示) (115)14.9.6 Cache Control Extensions (缓存控制扩展) (116)14.10 Connection (连接) (117)14.11 Content-Encoding (内容编码) (118)14.12 Content-Language (内容语言) (118)14.13 Content-Length (内容长度) (119)14.14 Content-Location (内容位置) (120)14.15 Content-MD5 (内容的MD5校验) (121)14.16 Content-Range (内容范围) (122)14.17 Content-Type (内容类型) (124)14.18 Date (日期) (124)14.18.1 Clockless Origin Server Operation (无时钟服务器操作)..12514.19 ETag (标签) (126)14.20 Expect (期望) (126)14.21 Expires (过期) (127)14.22 From (来自) (128)[页码5]------------------------------------------------------------------------14.23 Host (主机) (128)14.24 If-Match (如果匹配) (129)14.25 If-Modified-Since (如果自从某个时间已经更改) (130)14.26 If-None-Match (如果没有匹配) (132)14.27 If-Range (如果范围) (133)14.28 If-Unmodified-Since (如果自从某个时间未更改) (134)14.29 Last-Modified (最后更改) (134)14.30 Location (位置) (135)14.31 Max-Forwards (最大向前量) (136)14.32 Pragma (语法) (136)14.33 Proxy-Authenticate (代理鉴别) (137)14.34 Proxy-Authorization (代理授权) (137)14.35 Range (范围) (138)14.35.1 Byte Ranges (字节范围) (138)14.35.2 Range Retrieval Requests (范围重获请求) (139)14.36 Referer (引用自) (140)14.37 Retry-After (一会重试) (141)14.38 Server (服务器) (141)14.39 TE (142)14.40 Trailer (追踪者) (143)14.41 Transfer-Encoding(传输编码) (143)14.42 Upgrade (改良) (144)14.43 User-Agent (用户代理) (145)14.44 Vary (变更) (145)14.45 Via (经由) (146)14.46 Warning (警告) (148)14.47 WWW-Authenticate (WWW鉴别) (150)15 Security Considerations (对安全的考虑) (150)15.1 Personal Information(个人信息) (151)15.1.1 Abuse of Server Log Information (服务日志信息的滥用) (151)15.1.2 Transfer of Sensitive Information (敏感信息传输) (151)15.1.3 Encoding Sensitive Information in URI's(对URI中的敏感信息编码) (152)15.1.4 Privacy Issues Connected to Accept Headers(可接受头的秘密问题) (152)15.2 Attacks Based On File and Path Names基于文件名和路径的攻击 (153)15.3 DNS Spoofing (DNS欺骗) (154)15.4 Location Headers and Spoofing (位置头和欺骗) (154)15.5 Content-Disposition Issues (内容部署问题) (154)15.6 Authentication Credentials and Idle Clients(信用鉴定与空闲客户) (155)15.7 Proxies and Caching (代理与缓存) (155)15.7.1 Denial of Service Attacks on Proxies(对代理的服务拒绝攻击) (156)16 Acknowledgments (致谢) (156)17 References (参考) (158)18 Authors' Addresses (作者地址) (162)19 Appendices (附录) (164)19.1 Internet Media Type message/http and application/http(网络媒体类型:消息/HTTP和应用/HTTP) (164)19.2 Internet Media Type multipart/byteranges(网络媒体类型:多部分/字节范围) (165)19.3 Tolerant Applications (容错的应用) (166)19.4 Differences Between HTTP Entities and RFC 2045 Entities(HTTP的实体和RFC2045中实体的区别) (167)[页码6]------------------------------------------------------------------------19.4.1 MIME-Version (MIME版本) (167)19.4.2 Conversion to Canonical Form (语言形式转变) (167)19.4.3 Conversion of Date Formats (日期格式的转变) (168)19.4.4 Introduction of Content-Encoding (内容编码的介绍) (168)19.4.5 No Content-Transfer-Encoding (不要内容传输编码) (168)19.4.6 Introduction of Transfer-Encoding (传输编码的介绍) (169)19.4.7 MHTML and Line Length Limitations(MHTML与行长度限制) (169)19.5 Additional Features (附加的一些性质) (169)19.5.1 Content-Disposition (内容部署) (170)19.6 Compatibility with Previous Versions (与久版本的兼容性) (170)19.6.1 Changes from HTTP/1.0 (自HTTP/1.0的更改) (171)19.6.2 Compatibility with HTTP/1.0 Persistent Connections(与HTTP/1.1持久连接的兼容性) (172)19.6.3 Changes from RFC 2068 (自RFC268的更改) (172)20 Index (索引) (175)21 Full Copyright Statement (完整版权声明) (176)1 概述1.1 目的超文本传输协议(HTTP)是一种应用于分布式、合作式、多媒体信息系统的应用层协议。
Http协议规范

Http协议规范协议名称:HTTP协议规范背景介绍:HTTP(Hypertext Transfer Protocol)是一种用于传输超文本的应用层协议。
它是Web应用中最重要的协议之一,用于客户端和服务器之间的通信。
HTTP协议规范定义了请求和响应的格式、状态码、头部字段以及其他相关细节,确保了互联网上的信息交换的顺利进行。
一、协议版本HTTP协议目前有多个版本,包括HTTP/1.0、HTTP/1.1和HTTP/2等。
本协议遵循HTTP/1.1版本。
二、请求格式1. 请求行:请求行由请求方法、请求URI和协议版本组成,格式如下:```请求方法请求URI 协议版本```示例:GET /index.html HTTP/1.12. 请求头部:请求头部包含了请求的附加信息,格式为键值对,每个键值对占一行,以冒号分隔,示例如下:```键: 值```常见的请求头部字段有:- Host:指定请求的主机名和端口号- User-Agent:发送请求的用户代理信息- Accept:指定客户端可接受的MIME类型- Content-Type:指定请求体的MIME类型- Cookie:包含了客户端的Cookie信息3. 请求体:请求体是可选的,用于传输请求的数据,例如表单数据或上传的文件等。
三、响应格式1. 状态行:状态行由协议版本、状态码和状态描述组成,格式如下:```协议版本状态码状态描述```示例:HTTP/1.1 200 OK2. 响应头部:响应头部包含了响应的附加信息,格式同请求头部。
3. 响应体:响应体是服务器返回的实际内容,可以是HTML、JSON、图片等。
四、常见状态码1xx:信息性状态码,表示服务器接收到请求并继续处理。
2xx:成功状态码,表示服务器成功处理了请求。
3xx:重定向状态码,表示需要进一步操作以完成请求。
4xx:客户端错误状态码,表示客户端发送的请求有错误。
5xx:服务器错误状态码,表示服务器在处理请求时发生了错误。
HTTP协议详解(文档)

HTTP协议详解(⽂档)⽬录引⾔ (3)⼀、HTTP 协议详解之URL 篇 (3)⼆、HTTP 协议详解之请求篇 (3)三、HTTP 协议详解之响应篇 (4)四、HTTP 协议详解之消息报头篇 (5)1、普通报头 (5)2、请求报头 (6)3、响应报头 (7)4、实体报头 (7)五、利⽤telnet 观察http 协议的通讯过程 (8)1、打开telnet (8)2、连接服务器并发送请求 (9)3、实验结果: (9)4、注意事项 (10)六、HTTP 协议相关技术补充 (10)1、基础 (10)2、协议分析的优势—HTTP 分析器检测⽹络攻击 (11)3、HTTP 协议Content Lenth 限制漏洞导致拒绝服务攻击 (11)4、利⽤HTTP 协议的特性进⾏拒绝服务攻击的⼀些构思 (11)5、Http 指纹识别技术 (11)6、其他 (12)HTTP协议详解引⾔HTTP 是⼀个属于应⽤层的⾯向对象的协议,由于其简捷、快速的⽅式,适⽤于分布式超媒体信息系统。
它于1990 年提出,经过⼏年的使⽤与发展,得到不断地完善和扩展。
⽬前在WWW 中使⽤的是HTTP/1.0的第六版,HTTP/1.1 的规范化⼯作正在进⾏之中,⽽且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP 协议的主要特点可概括如下:1.⽀持客户/服务器模式。
2.简单快速:客户向服务器请求服务时,只需传送请求⽅法和路径。
请求⽅法常⽤的有GET、HEAD、POST。
每种⽅法规定了客户与服务器联系的类型不同。
由于HTTP 协议简单,使得HTTP 服务器的程序规模⼩,因⽽通信速度很快。
3.灵活:HTTP 允许传输任意类型的数据对象。
正在传输的类型由Content-Type 加以标记。
4.⽆连接:⽆连接的含义是限制每次连接只处理⼀个请求。
服务器处理完客户的请求,并收到客户的应答后,即断开连接。
采⽤这种⽅式可以节省传输时间。
Http协议规范

Http协议规范协议名称:HTTP协议规范一、引言HTTP(Hypertext Transfer Protocol,超文本传输协议)是一种用于传输超媒体文档(例如HTML)的应用层协议。
本协议规范旨在定义HTTP协议的工作原理、消息格式和状态码等相关内容,以便确保网络通信的可靠性和互操作性。
二、协议版本当前的HTTP协议版本为HTTP/1.1。
本规范基于该版本进行描述和解释。
三、协议通信模型HTTP采用客户端-服务器模型进行通信。
客户端发送请求消息给服务器,服务器返回响应消息给客户端。
通信过程通常包括以下步骤:1. 建立连接:客户端与服务器之间建立TCP连接。
2. 发送请求:客户端发送一个HTTP请求消息给服务器。
3. 处理请求:服务器接收并处理请求消息。
4. 发送响应:服务器发送一个HTTP响应消息给客户端。
5. 处理响应:客户端接收并处理响应消息。
6. 关闭连接:通信完成后,客户端和服务器断开TCP连接。
四、协议消息格式HTTP协议定义了请求消息和响应消息的格式。
请求消息由请求行、请求头部和请求主体组成,而响应消息由状态行、响应头部和响应主体组成。
1. 请求消息格式:请求行:包括请求方法、请求URI和协议版本。
请求头部:包括各种请求头字段,用于传递附加信息。
请求主体:可选,用于传递请求相关的数据。
2. 响应消息格式:状态行:包括协议版本、状态码和状态描述。
响应头部:包括各种响应头字段,用于传递附加信息。
响应主体:可选,用于传递响应相关的数据。
五、协议请求方法HTTP协议定义了多种请求方法,用于指定对资源的操作。
常见的请求方法包括:1. GET:获取资源。
2. POST:提交数据,创建资源。
3. PUT:更新资源。
4. DELETE:删除资源。
5. HEAD:获取资源的元信息。
6. OPTIONS:获取服务器支持的通信选项。
7. TRACE:追踪请求的路径。
六、协议状态码HTTP协议定义了多种状态码,用于表示请求的处理结果。
文本传输协议(修订编写)

超文本传送协议超文本传输协议bai (HTTP-Hypertext transfer protocol),是一种详细规du定了浏览器和万维网服务器之间互zhi相通信的规则,通dao过因特网传送万维网文档的数据传送协议。
它可以使浏览器更加高效,使网络传输减少。
它不仅能保证计算机正确快速地传输超文本文档,还能确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
HTTP协议即超文本传送协议。
超文本传输协议(HTTP-Hypertext transfer protocol) 是一种详细规定了浏览器和万维网服务器之间互相通信的规则,通过因特网传送万维网文档的数据传送协议。
目录1简史2协议简介3特点4请求信息5请求方法6响应头?响应头第一行?响应头域7安全协议8HTTP状态码1简史编辑超文本转移协议的前身是世外桃源(Xanadu)项目,超文本的概念是泰德˙纳尔森(Ted Nelson)在1960年代提出的。
进入哈佛大学后,纳尔森一直致力于超文本协议和该项目的研究,但他从未公开发表过资料。
1989年,蒂姆˙伯纳斯˙李(Tim Berners Lee)在CERN(欧洲原子核研究委员会= European Organization for Nuclear Research)担任软件咨询师的时候,开发了一套程序,奠定了万维网(WWW = World Wide Web)的基础。
1990年12月,超文本在CERN首次上线。
1991年夏天,继Telnet等协议之后,超文本转移协议成为互联网诸多协议的一分子[1]。
当时,Telnet协议解决了一台计算机和另外一台计算机之间一对一的控制型通信的要求[2]。
邮件协议解决了一个发件人向少量人员发送信息的通信要求。
文件传输协议解决一台计算机从另外一台计算机批量获取文件的通信要求,但是它不具备一边获取文件一边显示文件或对文件进行某种处理的功能。
新闻传输协议解决了一对多新闻广播的通信要求。
HTTP简介.

HTTP响应消息
响应消息的结构:
一个状态行、若干消息头、以及实体内容 ,其中的一些消息头和实体 内容都是可选的,消息头和实体内容之间要用空行隔开。
举例:
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Thu, 13 Jul 2000 05:46:53 GMT Content-Length: 2291 Content-Type: text/html Cache-control: private <HTML> <BODY> ……
消息头又可以分为通用信息头、请求头、响应头、实体头等四 类。 许多请求头字段都允许客户端在值部分指定多个可接受的选项 ,多个项之间以逗号分隔。 有些头字段可以出现多次。
请求行与状态行
请求行
格式:请求方式 资源路径 HTTP版本号<CRLF> 举例:GET /test.html HTTP/1.1 请求方式:POST、HEAD、OPTIONS、DELETE、TRACE、PUT
状态行
格式: HTTP版本号 状态码 原因叙述<CRLF> 举例:HTTP/1.1 200 OK
使用GET和POST方式传递参数
在URL地址后面可以附加一些参数
举例:/servlet/ParamsServlet?param1=abc¶m2=xyz
500(内部服务器错误)
服务器端的CGI、ASP、JSP等程序发生错误。
通用信息头
通用信息头字段既能用于请求消息,也能用于响应消息,它包括一 些与被传输的实体内容没有关系的常用消息头字段。
WebSocket 协议(RFC6455)中文翻译版(word版)

WebSocket 协议(RFC6455)中文翻译版(word版)翻译自:/rfc/rfc6455.txtInternet Engineering Task Force (IETF) I. FetteRequest for Comments: 6455 Google, Inc.Category: Standards Track A. MelnikovISSN: 2070-1721 Isode Ltd. December 2011WebSocket 协议摘要WebSocket协议使在控制环境下运行不受信任代码的客户端和能够选择与那些代码通信的远程主机之间能够双向通信。
用于这个的安全模型是以origin为基础的安全模型,一般被浏览器使用。
协议包含打开握手,其次是基本消息框架,在 TCP 之上。
这项技术的目的是为基于浏览器的、需要与服务器双向通信的应用程序提供一种不依赖于打开多个HTTP连接的机制(例如,使用XMLHttpRequest或<iframe>和长轮询)。
本备忘录的状态这是一个Internet标准跟踪文件。
这个文档是因特网工程师任务组(IETF)的一个产品。
它代表了IETF社区的共识。
它已接受公众审查,因特网工程指导组(IESG)证明可出版。
关于互联网标准的进一步信息在RFC5741的第2章节。
关于本文档当前状态的信息、勘误表和如何提供反馈,可以在/info/rfc6455找到。
版权声明Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.1 介绍1.1 背景这部分是不规范的。
http通信协议

http通信协议1. 简介HTTP(Hypertext Transfer Protocol)是一种用于传输超文本的应用层协议。
它是Web数据通信的基础,通过在客户端和服务器之间进行请求和响应来实现数据传输。
HTTP通信协议基于TCP/IP协议,使用可靠的连接,通常通过端口80进行通信。
它是一种无状态的协议,每个请求和响应之间是独立的,服务器不会维持任何客户端的状态信息。
2. HTTP请求HTTP请求由客户端发送给服务器,包含以下几个部分:请求行请求行包含请求方法、URL和协议版本,格式如下:请求方法 URL 协议版本常见的请求方法有GET、POST、PUT、DELETE等。
请求头请求头包含了关于请求的附加信息,格式为键值对,每个键值对占据一行。
常见的请求头有:•Host:指定服务器的域名或IP地址•User-Agent:指定客户端的信息•Content-Type:指定请求体的MIME类型•Cookie:指定客户端的Cookie信息请求体一些请求需要在请求体中传递数据,比如POST请求。
请求体的内容格式由Content-Type字段决定。
3. HTTP响应HTTP响应由服务器发送给客户端,包含以下几个部分:状态行状态行包含协议版本、状态码和状态消息,格式如下:协议版本状态码状态消息常见的状态码有200(成功)、404(未找到)、500(服务器内部错误)等。
响应头响应头包含了关于响应的附加信息,格式和请求头类似。
常见的响应头有:•Content-Type:指定响应体的MIME类型•Content-Length:指定响应体的长度•Set-Cookie:指定服务器返回的Cookie信息响应体响应体包含了实际的响应数据,格式由Content-Type字段决定。
4. HTTP状态管理由于HTTP协议是无状态的,为了在多个请求之间保持状态,服务器通过Cookie和Session来实现状态管理。
CookieCookie是服务器在HTTP响应头中返回给客户端的一小段数据。
超文本传输协议 -- HTTP11(RFC 2616中文版) 中.

超文本传输协议 -- HTTP/1.1(RFC 2616中文版中13 HTTP中的缓存HTTP 典型应用于能通过采用缓存技术而提高性能的分布式信息系统。
HTTP/1.1协议包括的许多使缓存尽可能的工作的元素。
因为这些元素与协议的其他方面有着千丝万缕的联系,而且他们相互作用、影响,因此有必要单独的来介绍基本的缓存设计。
如果缓存不能改善性能, 他将一无用处。
HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求,同时在许多情况下可以不需要发送完整响应。
前者减少了网络回路(译注:一个请求会返回一个响应,请求响应这个过程就是一个回路的数量;我们利用一个“过期(expiration ”机制来为此目的(见 13.2节。
后者减少了网络应用的带宽;我们用“验证(validation ”机制来为此目的。
对行为, 可行性, 和关闭的操作的要求放松了语义透明性的目的。
HTTP/1.1协议允许服务器, 缓存,和客户端能显示地降低透明性当在必要的时候。
然而,因为不透明的操作能混淆非专业的用户, 同时可能和某个服务器应用程序不兼容 (例如订购商品 , 因此此协议透明性在下面情况下才能被放松要求:-- 只有在一个显示的协议层的请求时,透明性才能被客户端或源服务器放松-- 当出现一个对终端用户的显示的警告时,透明性才能被缓存或被客户端放松因此, HTTP/1.1协议提供这些重要的元素:1.提供完整语义透明的协议特征,当这些特征被通信的所有方需要时2. 允许源服务器或用户代理显示的请求和控制不透明操作的协议特征3. 允许缓存给这样的响应绑定警告信息的协议特征, 这些响应不能保留请求的语义透明的近似一个基本的原则是客户端必须能够发现语义透明性的潜在的放松。
注意:服务器,缓存,或者客户端的实现者可能会面对设计上的判断,而这些判断没有显示地在此规范里讨论。
如果一个判断可能会影响语义透明性,那么实现者应该能维持语义透明性,除非一个仔细的完整的分析能说明打破透明性的好处。
HTTP 1.1与HTTP 1.0的比较

HTTP 1.1与HTTP 1.0的比较一个WEB站点每天可能要接收到上百万的用户请求,为了提高系统的效率,HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。
但是,这也造成了一些性能上的缺陷,例如,一个包含有许多图像的网页文件中并没有包含真正的图像数据内容,而只是指明了这些图像的URL地址,当WEB浏览器访问这个网页文件时,浏览器首先要发出针对该网页文件的请求,当浏览器解析WEB服务器返回的该网页文档中的HTML 内容时,发现其中的<img>图像标签后,浏览器将根据<img>标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求,如图3.3所示。
图3.3显然,访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应,每次请求和响应都需要建立一个单独的连接,每次连接只是传输一个文档和图像,上一次和下一次请求完全分离。
即使图像文件都很小,但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程,并且会严重影响客户机和服务器的性能。
当一个网页文件中包含Applet,JavaScript文件,CSS 文件等内容时,也会出现类似上述的情况。
为了克服HTTP 1.0的这个缺陷,HTTP 1.1支持持久连接,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。
一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。
RFC2617 中文版

1.备忘 (3)2.版权申明 (3)3.摘要 (3)4.授权鉴别 (4)4.1.对HTTP/1.1规范的依赖 (4)4.2.访问鉴别框架 (4)5.基本鉴别方案 (6)6.摘要访问鉴别方案 (8)6.1.介绍 (8)6.1.1.目的 (8)6.1.2.操作概述 (8)6.1.3.摘要值的表示 (8)6.1.4.该方案的局限性 (8)6.2.摘要报头的规范 (9)6.2.1.WWW-Authenticate响应报头 (9)6.2.2.Authorization请求报头 (11)6.2.3.Authentication-info报头 (15)6.3.摘要操作 (17)6.4.安全协议讨论 (17)6.5.例子 (18)6.6.代理鉴别和代理授权 (18)7.安全考虑 (20)7.1.客户使用基本鉴别 (20)7.2.客户使用摘要鉴别 (20)7.3.受限的NONCE值使用 (21)7.4.基本鉴别与摘要鉴别的比较 (21)7.5.回放式攻击 (22)7.6.多方鉴别方案产生的缺点 (22)7.7.在线字典攻击 (23)7.8.中间人 (23)7.9.选择纯文本攻击 (23)7.10.预先计算的字典攻击 (24)7.11.批处理方式暴力攻击 (24)7.12.假冒服务器欺骗 (24)7.13.存储口令 (24)7.14.总结 (25)8.例子实现 (26)9.参考书目 (30)10.作者地址 (30)11.完整版权申明 (30)12.致谢 (30)1.备忘本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。
详情请参见官方文件(STD1)。
本文可任意分发。
2.版权申明Copyright (C) The Internet Society (1999). All Rights Reserved3.摘要“HTTP/1.0”中包括基本访问鉴别方案(Basic Access Authentication scheme)。
HTTP+RFC文档中文版

HTTP+RFC文档中文版HTTP协议(RFC中文版)1. 介绍(Introduction)1.1 目的(Purpose)HTTP(Hypertext Transfer Protocol)是应用级协议,它适应了分布式超媒体协作系统对灵活性及速度的要求。
它是一个一般的、无状态的、基于对象的协议,通过对其请求方法(request methods)进行扩展,可以被用于多种用途,比如命名服务器(name server)及分布式对象管理系统。
HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。
HTTP自从1990年就在WWW上被广泛使用。
该规范反映了“HTTP/1.0”的普通用法。
该规范描述了在大多数HTTP/1.0客户机及服务器上看起来已经实现的特性。
规范将被分成两个部分:HTTP特性的实现是本文档的主要内容,而其它不太通行的实现将被列在附录D中。
实用的信息系统需要更多的功能,而不仅仅是数据的获取,包括搜索、前端更新及注解。
HTTP允许使用开放的命令集来表示请求的目的,它使用基于URI[2](Uniform Resource Identifier),即统一资源标识的规则来定位(URL[4])或命名(URN[16])方法所用到的资源。
HTTP使用与邮件(Internet Mail [7])和MIME(Multipurpose Internet Mail Extensions [5])相似的格式来传递消息。
HTTP也作为用户代理、代理服务器/网关与其它Internet协议进行通讯的一般协议,这些协议是,SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8]等。
HTTP允许不同的应用可以进行基本的超媒体资源访问,并简化用户代理的实现。
1.2 术语(Terminology)本规范用了许多与参与方、对象及HTTP通讯相关的术语,如下:连接(connection)两个应用程序以通讯为目的在传输层建立虚拟电路。
HTTP2.0协议中英文对照版

HTTP2.0协议中英文对照版超文本传输协议版本 2IETF HTTP2草案(draft-ietf-httpbis-http2-13)摘要本规范描述了一种优化的超文本传输协议(HTTP)。
HTTP/2通过引进报头字段压缩以及多路复用来更有效利用网络资源、减少感知延迟。
另外还介绍了服务器推送规范。
本文档保持对HTTP/1.1的后向兼容,HTTP的现有的语义保持不变。
1 介绍The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format ([RFC7230], Section 3) was designed to be implemented with the tools at hand in the 1990s, not modern Web application performance. As such it has several characteristics that have a negative overall effect on application performance today.超文本传输协议(HTTP)是一个非常成功的协议。
但是HTTP/1.1 是针对90年代的情况而不是现代web应用的性能而设计的,导致它的一些特点已经对现代应用程序的性能产生负面影响。
In particular, HTTP/1.0 only allows one request to be outstanding at a time on a given connection. HTTP/1.1 pipelining only partially addressed request concurrency and suffers from head-of-line blocking. Therefore, clients that need to make many requests typically use multiple connections to a server in order to reduce latency.特别是,HTTP/1.0只允许在一个连接上建立一个当前未完成的请求。
rfc2068中文(http)

直接(first-hand)
如果一个应答直接到来并且没有缘于原服务器,或若干代理服务器的不必要的延时,那么这个应答就是直接的.如果它的有效性已经被原服务器直接认证,那么这个应答也同样是第一手的.
明确终止时间(explicit expiration time)
原服务器预算一个实体在无需进一步确认的情况下不再被高速缓存返回的时间.
为请求服务时选择适当表示方法的机制(mechanism),如第12节所述.任何应答里实体的表示方法都是可协商的(包括出错应答).
变量(Variant)
在任何给定时刻,与一个资源对应的表示方法可以有一个或更多.每个表示方法称作一个变量.使用变量这个术语并不必然意味着资源是由内容协商决定的.
客户机(Client)
服务器用包括消息协议版本和成功或错误代码的状态进行应答,继以包括服务器信息,实体维护信息和可能的实体内容的类MIME消息。HTTP和MIME之间的关系如附录19.4节所阐述。
大部分的HTTP通信由用户代理引发,由应用到一些原服务器上资源的请求构成。最简单的情形,可以经用户代理(UA)和原服务器(O)之间的单一连接(v)完成。请求链------------------------>用户代理(UA)-------------------单一连接(v)-------------------原服务器(O) <-----------------------应答链
向内/向外(inbound/outbound)
向内和向外指的是消息的请求和应答路径:"向内"即"移向原服务器","向外"即"移向用户代理".
Copyright (2007). All Rights Reserved.
超文本传输协议(HTTP1.1)中文.

应用层超文本传输协议(HTTP)一、前言TCP/IP应用层协议有许多种,本文档讲解我们最熟悉的超文本传输协议(HTTP)。
超文本传输协议(HTTP)版本1.1是一个草案标准,其描述见RFC 2612。
旧的HTTP 1.0是一个指示性协议,RFC 1945对它进行了描述。
超文本传输协议是为了传输超文本标记语言(Hypertext Markup Language,HTML)而设计的协议。
HTML是一种用于创建超文本文档的标记语言。
有关HTML的信息请参见相关的超文本标记语言的书籍。
二、HTTP综述HTTP基于请求—响应活动。
客户端运行浏览器应用程序,它建立与服务器的连接,并以请求的形式发送一个请求到服务器。
服务器用一个状态行做出响应,包括信息的协议版本以及成功或者错误代码,后面跟着一个消息,它包含服务器信息、实体信息和可能的内容。
HTTP事务被划分为如下4个步骤。
除了实验性应用程序之外,现行习惯要求客户在发出每个请求之前先建立连接,并由服务器在发送响应之后关闭连接。
客户和服务器都应当注意任何一方都有可能过早地关闭连接,原因可能是用户操作、自动超时或者程序故障等,他们应当以一种可预见的并且所期望的方式处理这种关闭行为。
在任何一种情况下,任何一方或者双方关闭的连接总是终止当前请求,而不管它的状态如何。
简单的说HTTP是一种无状态协议,因为它不跟踪连接。
例如:为了装入包含两个图形的页面,支持图形的浏览器将打开三个TCP连接:一个连接用于页面,而另外连个连接用于图形。
然而大多数浏览器能够同时处理几个这样的连接。
如果一个页面包含大量要素,每个资源都新建一个TCP连接,这将占用大量资源。
在HTTP1.1中缓和了这个问题,它为每种类型元素建立一个TCP连接,同样类型的元素使用同一个TCP连接。
HTTP 1.1不同于HTTP 1.0的地方就是它使用了永久连接。
三、统一资源标识URIURI亦可称为web地址,是统一资源定位器(URL)和统一资源名称(URN)的组合。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
内容协商(content negotiation) 任 当服务一个请求时选择资源的一种适当的表示形式的机制(mechanism),如第 12 节所述。 何响应里实体的表现形式都是可协商的(包括错误响应)。 变量(variant) 在 某 个时 刻 ,一个资源对应的表现形式( representation )可以有一个或多个(译注:一个 URI 请求一个资源,但返回的是此资源对应的表现形式,这根据内容协商决定)。每个表现形 式 ( representation ) 被 称 作 一 个 变 量 。 ‘ 变 量 ’ 这 个 术 语 的 使 用 并 不 意 味 着 资 源 (resource)是由内容协商决定的.。 客户端(client) 为发送请求建立连接的程序.。 用户代理(user agent) 初始化请求的客户端程序。常见的如浏览器,编辑器,蜘蛛(可网络穿越的机器人),或其他 的终端用户工具. 服务器(Server) 服务器是这样一个应用程序,它同意请求端的连接,并发送响应( response)。任何给定的程 序都有可能既做客户端又做服务器;我们使用这些术语是为了说明特定连接中应用程序所担当 的角色,而不是指通常意义上应用程序的能力。同样,任何服务器都可以基于每个请求的性质 扮演源服务器,代理,网关,或者隧道等角色之一。 源服务器(Origin server) 存在资源或者资源在其上被创建的服务器(server)被成为源服务器(origin server)。 代理( Proxy) 代理是一个中间程序,它既可以担当客户端的角色也可以担当服务器的角色。代理代表客户端 向服务器发送请求。客户端的请求经过代理,会在代理内部得到服务或者经过一定的转换转至 其 他 服务器。一个代理必 须 能同时实现本规范 中 对 客 户端和服务器 所 作的要求。 透 明代理 ( transparent proxy )需要代理 认证 和代理识 别 , 而 不修 改 请求或响应。 非透 明代理( nontransparent proxy)需修改请求或响应,以便为用户代理( user agent)提供附加服务,附加 服务包括组注释服务,媒体类型转换,协议简化,或者匿名过滤等。除非透明行为或非透明行 为经被显式地声明,否则,HTTP 代理既是透明代理也是非透明代理。 网关(gateway) 网关其实是一个服务器,扮演着代表其它服务器为客户端提供服务的中间者。 与代理(proxy) 不同,网关接收请求,仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同 网关通信。 隧道(tunnel) 隧道也是一个中间程序,它一个在两个连接之间充当盲目中继(blind relay)的中间程序。 一旦 隧道处于活动状态,它不能被认为是这次 HTTP 通信的参与者,虽然 HTTP 请求可能已经把它 初始化了。当两端的中继连接都关闭的时候,隧道不再存在。 缓存(cache) 缓存是程序响应消息的本地存储。 缓存是一个子系统,控制消息的存储、 获取和删除。 缓存里存 放可缓存的响应( cacheable response)为的是减少对将来同样请求的响应时间和网络带宽消 耗。 任一客户端或服务器都可能含有缓存,但缓存不能存在于一个充当隧道(tunnel)的服务器 里。
实际的信息系统除了简单的获取信息之外,还要求更多的功能,包括查找( search),终端更 新( front-end update )和注解( annotation )。 HTTP 为请求提供可扩充方法集和消息头集 [47]。HTTP 是建立在统一资源标识符(URI)[3]的约束上的,作为一个地址(URL)[4]或名称 (URN)[20],以指定被一个方法使用的资源。消息以一种类似于互联网邮件 [9]消息格式来传 输的,互联网消息格式定义于多目的互联网邮件扩展(MIME)[7]里。 HTTP 也是用于用户代理( user agents)和其它互联网系统的代理 /网关之间通信的通信协议, 这些互联网系统可能由 SMTP[16],NNTP[13],FTP[18],Gopher[2]和 WAIS[10]协议支持。通过 这种方式,HTTP 允许不同的应用程序对资源进行基本的超媒体访问。
摘要
超文本传输协议(HTTP)是一种为分布式,协作式的,超媒体信息系统。 它是一种通用的,无 状态(stateless)的协议,除了应用于超文本传输外,它也可以应用于诸如名称服务器和分布 对象管理系统之类的系统,这可以通过扩展它的请求方法,错误代码和消息头 [47] 来实现 。 HTTP 的一个特性就是是数据表现形式是可以定义的和可协商性的,这就允许系统能独立于于 数据传输被构建。 HTTP 在 1990 年 WWW 全 球 信 息 刚 刚 起 步 的 时 候 就 得 到 了 应 用 。 本 说 明 书 详 细 阐 述 了 HTTP/1.1 协议,是 RFC 2068 的修订版[33]。
1.3 术语
本说明用到了若干术语,以表示 HTTP 通信中各参与者和对象扮演的不同角色。 连接(connection) 为通信而在两个程序间建立的传输层虚拟电路。 消息(message) HTTP 通信中的基本单元。它由一个结构化的八比特字节序列组成,与第 4 章定义的句法相匹 配,并通过连接得到传送。 请求(request) 一种 HTTP 请求消息,参看第 5 章的定义。 响应(response) 一种 HTTP 响应消息,参看第 6 章的定义。 资源(resource) 一种网络数据对象或服务,可以用第 3.2 节定义的 URI 指定。资源可以以多种表现方式(例如 多种语言,数据格式,大小和分辨率)或者根据其它方面而而不同的表现形式。 实体(entity) 实体是请求或响应的有效承载信息。一个实体包含元信息和内容,元信息以实体头域( entityheader field)形式表示,内容以消息主体(entity-body)形式表示。在第 7 章详述。 表现形式 (representation) 一个响应包含的实体是由内容协商(content negotiation)决定的。 如第 12 章所述。 有可能存在 一个特定的响应状态码对应多个表现形式。
目录(略)
1 引论
1.1 目的
超文本传输协议(HTTP)是一种为分布式的,协作的,超媒体信息系统,它是面向应用层的 协议。 在 1990 年 WWW 全球信息刚刚起步的时候 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/1.1(修订版)
说明
本文档规定了互联网社区的标准组协议,并需要讨论和建议以便更加完善。请参考 “互联网官方协议标准”(STD 1)来了解本协议的ght (C) The Internet Society (1999). All Rights Reserved.
1.2 要求
本 文 的 关 键 词 “ 必 须 ” ( "MUST" ) , , “ 不 能 ” ( "MUST NOT" ) , “ 需 要 ” ( "REQUIRED" ) , “ 应 该 ” ( "SHALL" ) , “ 不 应 该 ” ( "SHALL NOT" ) , “ 应 该 ” ( "SHOULD" ) , “ 不 应 该 ” ( "SHOULD NOT" ) , “ 建 议 的 ” ( "RECOMMENDED" ),“可能”( "MAY" ), 和“可 选 的”( "OPTIONAL" ) 将 由 RFC 2119[34]解释。 一个应用程序如果不能满足协议提供的一个或多个 MUST 或 REQUIRED 等级的要求,是不符 合要求的。一个应用程序如果满足所有必须( MUST)或需要的(REQUIRED)等级以及所有 应该 ( SHOULD ) 等级 的要求, 则被称为 非条 件遵循(unconditionally compliant )的;若满 足所有必须(MUST)等级的要求但不能满足所有应该( SHOULD)等级的要求则被称为条件 遵循的(conditionally compliant)。