HTTP协议-最新RFC文档-中文版

合集下载

http协议详解(超详细)

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协议解说

(完整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 中文版

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 中文文档

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协议规范背景介绍: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协议详解(文档)

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协议规范一、引言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]。

邮件协议解决了一个发件人向少量人员发送信息的通信要求。

文件传输协议解决一台计算机从另外一台计算机批量获取文件的通信要求,但是它不具备一边获取文件一边显示文件或对文件进行某种处理的功能。

新闻传输协议解决了一对多新闻广播的通信要求。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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)。
相关文档
最新文档