8 连接(Connections) 持久HTTP连接具有一下优势: l 通过打卡和关闭更少的TCP连接,节省了路由和主机的CPU耗时,以及TCP协议控制阻塞使用的主机内存。 l HTTP请求和响应可以在一个连接的基础上管道化。管道技术允许客户端发送多个请求而不用等待响应,使得TCP连接更加高效地使用从而更少的浪费时间。 l 通过减少TCP打开导致的包的消息来减少网络拥塞,通过给TCP充分的时间来确定网络的拥塞状态。 l HTTP可以进化的更加优美,因为错误可以被报告而不用直接关闭TCP连接。使用高HTTP版本的客户端可能尝试一些新的功能,但是如果与旧版本服务端通信时在有错误报告后用要重试旧的语义。 HTTP实现应该实现持久连接。 8.1.2 概述(Overall Operation) 持久化连接提供了一个机制可以让客户端和服务端给出TCP连接关闭的信号。信号用Connection报头域给出(14.10章)。一旦关闭信号发出,客户端就不能再通过那个连接发送任何请求。 8.1.2.1协商( Negotiation) HTTP/1.1客户端可以认为一个连接是始终打开的,但决定其保持打开是基于服务端的响应里是否包含一个有关闭连接符的Connection报头。如果客户端不想在请求之后继续持有连接,那么他应该发送一个有关闭连接符号的Connection报头。 如果客户端或者服务端发送了有关闭符号的Connection报头,那个请求就是连接的最后一次使用。 为了保持持久连接,所有经由连接的消息都必须有一个自定义的消息长度(例如关闭连接所没有定义的那个),4.4章对消息长度有描述。 8.1.2.2流水线( Pipelining) 采取持久化连接和在创建连接后立即管道化的客户端应该在其第一次管道化尝试失败时重试其连接。如果客户端进行这样的重试,它在确定连接是持久的之前不能进行管道化。客户端也必须准备好重发那些请求,如果服务端在没有返回相应响应就关闭了连接的话。 客户端不应该使用non-idempotent方法或者non-idempotent方法序列来管道化请求。否则的话,一个传输连接的过早的中止可能会导致不确定的结果。那些想发送non-idempotent请求的客户端应该等到它接收到前一个请求的响应状态码之后再发送请求。 8.1.3代理服务器(Proxy Servers) 代理服务器必须分别想其连接的客户端和源服务端(或者是另一个代理服务器)通知持久化连接。没一个持久化连接只能应用到一个传输链接上。 代理服务器不能同HTTP/1.0客户端创建一个HTTP/1.1连接。(不过可以看一下RFC 2068 [33]关于一些HTTP/1.0客户端实现的Keep-Alive报头的信息和问题讨论)。 8.1.4实际应用的考虑(Practical Considerations) 当一个客户端或者服务端认为超时时它应该给传输连接一个完美的中断。客户端和服务端都应该密切监视对方的传输中断,并做出适当的响应。如果客户端或者服务没有察觉对方的关闭可能会导致不必要的网络资源浪费。 客户端、服务端或者代理可能会在任何时候关闭传输连接。例如一个客户端可能已经发送新请求的同时服务端也决定关闭这个无用的连接。从服务的角度看是在关闭失效的连接,但客户端的角度则是正在发送一个请求。 这意味着客户端、服务端和代理应该有能力从异步连接关闭事件中恢复过来。客户端应该重新打开传输连接并且重发失败了请求序列而不用用户交互,只要请求序列是等价的(idempotent)(参看9.1.2章)不等价的方法或者序列不能自动重发,尽管用户代理可能会提交给用户一个重发请求的选择。有程序语义识别的用户代理可以代理用户做出确认。自动重发在第二次请求失败后不应该继续重复。 服务端应该始至少响应每个连接中的一个请求,如果可能的话。服务端不应该在传输响应的中途关闭连接,除非是网络或者客户端错误。 使用持久连接的客户端应该限制其与给定服务端维持的并行性连接数量。一个单用户保持的域服务器或者代理的连接不应该超过2个。代理应该使用最多2*N个与服务或者代理的连接,这里N是并发的活跃用户的数目。这些指导意见是用来改善HTTP响应时间并避免拥塞。 8.2 消息传输需求Message Transmission Requirements 8.2.2 监控连接中的错误信息Monitoring Connections for Error Status Messages 8.2.3状态100的使用 Use of the 100 (Continue) Status 对HTTP/1.1客户端的要求: l 如果客户端在发送请求主体前会等待一个100(Continue)响应,它必须发送一个有“100-continue”预期的请求报头。 l 客户端不能发送一个有“100-continue”请求报头域的请求,如果它不打算发送请求主体。 由于有老版本的实现,协议允许不明确的状态,这样客户端可以发送“Expect: 100-continue”而不用收到417(期望失败)或者100(继续)状态。因此,当客户端发送一个报头域给源服务端(或许经由代理)但未收到100(Continue)状态时,客户端不应该无限等待下去。 对HTTP/1.1源服务端的要求: l 当接收到一个包含带有“100-continue”期望报头域的请求后,源服务端必须要么返回100(Continue)状态继续读取输入流,要么给出一个最终响应代码。服务端在发出100(Continue)响应之前不能等待请求主体。如果给出的是最终状态码,服务端可以关闭传输连接,也可以继续读取并丢弃请求的剩余部分。服务端不能执行请求的方法,如果它返回的是一个最终状态码。 l 一个源服务端不应该在请求信息里没有“100-contiune”期望报头域的情况下返回100(Continue)响应,如果请求来自HTTP/1.0服务器那么它也不能返回100状态。这个规则有一个例外就是:为了兼容草案2068,服务端可以发送一个100状态响应给一个,没有包含有“100-continue”期望请求报头域的HTTP/1.1的PUT或者POST请求。这个例外的目的是为了最小化客户端处理未声明的等待100状态造成的延迟,这只能应用于HTTP/1.1请求,不针对其他HTTP版本。 l 一个源服务应该不再发送一个100响应,如果它已经接收到相应请求的部分或者全部的请求实体。 l 一个发送过100响应的源服务端必须在请求实体接收并处理后发送一个最终状态代码,除非它提前中止了传输连接。 l 如果源服务接收到一个不包括含有“100-continue”期望值的期望请求报头域,请求包含一个请求实体,并且服务在从传输连接中读取全部请求体之前发送了最终状态码,那么服务端不应该关闭传输连接知道它已经读取了全部请求,或者知道客户端关闭了连接。否则的话,客户端可能没有可靠地接收响应信息。虽然如此,这个要求不是妨碍服务端防止拒绝服务式攻击或者有严重缺陷的客户端实现。 对HTTP/1.1代理的要求: l 如果代理接收到一个包含有“100-continue”期望值的期望请求报头域的请求,并且代理知道下一环服务端是HTTP/1.1或者更高版本,或者不知道下一环服务器HTTTP版本,它必须传递请求,包括期望报头域。 l 如果代理知道下一环服务端是HTTP/1.0或者更低的版本,它必须不转寄请求,并且要返回一个417(期望失败)状态。 l 代理应该缓存最近引用的下一环服务器的HTTP版本号。 l 代理必须不能转寄100响应,如果请求消息来自于HTTP/1.0(或者更早的版本)客户端并且不包含有“100-continue”期望值的期望请求报头域。这个要求不考虑推进1xx响应的一般规则。 8.2.4服务端过早关闭连接后的客户端行为 Client Behavior if Server Prematurely Closes Connection 1. 创建一个到服务端的新连接 2. 传输请求报头域 3. 用估计服务的反馈时间(例如基于它创建连接所用的时间),或者一个5秒的常值来初始化一个变量R 4. 计算 T = R*(2**N),N是上一次重试的次数。 5. 等待到从服务返回一个错误响应,或者T秒(两者最先的那个)。 6. 如果没有错误返回,在T秒后传输请求实体。 7. 如果客户端发现连接提前关闭了,返回到步骤1知道请求被接收、接收到错误的响应或者用户不耐烦并中止重试过程。 如果在任一步接收到一个错误的状态,客户端 l 不应该继续并且 l 应该关闭连接,如果它没有完成请求信息的发送。 9方法定义Method Definitions Host请求报头域必须存在于所有的HTTP/1.1请求。 9.1 安全和冥等的方法Safe and Idempotent Methods 特别指出的是,按照协定GET和HEAD方法不应该有出获取资源以外的能力。这些方法应该被认为是安全的。这就允许用户代理用特殊的方式来表现其他的方法,例如GET、PUT和DELETE,这样用户就可以知道请求的是一个可能不安全的动作。 自然地,不能保证服务端执行GET请求时不会产生副作用;事实上,一定动态资源认为它一个特性。这最重要的区别是用户没有请求副作用,因为不应该让他们承担责任。 9.1.2 冥等的方法Idempotent Methods 虽然如此,一些请求的序列可能是非冥等的,即使所有在序列中执行的方法是冥等的。(一个序列是冥等的是指整个序列的一次单独执行结果不会因为重新执行该序列的全部或者部分而改变。)例如,如果序列的结果依赖于一个可能稍后会在同一个序列中做出修改的值,则该序列是非冥等的。 根据定义,没有副作用的序列是冥等的(前提是没有并发的操作在同一个资源上执行) 9.2 OPTIONS 这个方法的响应是不可缓存的。 如果OPTIONS请求含有实体主体,那么必须通过一个Content-type域来指定媒体类型。虽然本规范里并没有定义怎样使用这个主体,将来的HTTP版本可能或使用OPTIONS主体对服务端做更详细的查询。如果服务器不支持这样的扩展可以丢弃请求主体。 如果请求URI是一个星号(*), OPTIONS请求只是对服务器自身的一般应用而不是针对特定资源。例如,它可以被用来测试代理对HTTP/1.1的兼容性。 如果请求URI不是星号,那么OPTIONS请求只是申请当与资源通讯时有效的选项。 一个200响应应该包含一些报头域来值标示服务端实现的功能选项或者资源的可用性(若Allow),也肯包含一些本规范里为定义的扩展。响应主体,如果有的话,也应该包含通讯选项的相关信息。这种主体的格式规范没有去定义,但是可能在将来的HTTP扩展里定义。内容协商可能会用来选择适当的响应格式。如果响应不包哈响应主体,那么它应该给出一个域值为“0”的Content-Length域。 Max-Forwards请求报头域可以用来选择请求链中的特定代理。当一个代理收到可以继续传播的绝对URI的OPTIONS请求时,代理必须检查Max-Forwards报头域。如果Max-Forwards报头域的值是零(“0”),代理不能转发消息;取而代之,代理应该响应其自身的通讯选项。如果Max-Forwards域值是一个大于0的整数,代理必须在转发请求时递减这个域值。如果没有Max-Forwards域出现在请求里,转发的请求里也绝不能包含Max-Forwards域值。 9.3 GET 如果请求信息包含If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match或者 If-Range报头域,那么GET方法的语义将变成“conditional GET”。一个条件GET方法请求只有在条件报头域描述的环境下实体才会被传输。条件GET方法允许刷新缓存实体而不用提出多个请求或者传输客户端已经拥有的数据,籍此减少不必要的网络使用。 如果请求信息里包含Range报头域,GET方法的语义会变为“partial GET”。一个部分GET请求只传输实体的一部分,参考14.35章的描述。部分GET方法是通过允许部分获取实体而不用传输客户端已拥有的数据来减少网络的使用。 GET请求的响应可以缓存,条件是当且仅当其符合13章描述的HTTP缓存要求。 参看15.1.14章使用表单时的安全考虑。 9.4 HEAD 如果响应信息可以用来更新一个以前缓存的来自资源的实体,那么HEAD请求的响应是可以缓存的。如果新的域值指出缓存的实体不同于当前的实体(可能是Content-Length, Content-MD5, ETag 或者 Last-Modified的改变),缓存应该将缓存的实体丢弃。 9.5 POST l 声明存在资源; l 投递消息给一个公告板、新闻组、邮件列表或者类似的主题。 l 提供数据块给一个数据处理进程,如提交表单的结果。 l 通过增加操作来扩充数据库。 POST所提供的实际功能取决于服务端并且通常受制于请求URI。投送的实体从属于URI如同文件从属于拥有它的路径一样,就像一个新的文章从属于它投递的新闻组,或者记录从属于数据库。 POST方法执行的动作可能不会生成可以通过URL可以指定的资源。这种情况下,200(OK)或204(无内容)谁是一个恰当的响应状态,依赖于响应是否包含一个描述结果的实体。 如果服务端已经创建了资源,响应应该是201(Created)并且包含一个描述了请求状态和新资源相关的实体,以及一个Location报头(参看14.30章)。 这个方法的响应是不能缓存的,除非响应包含适当的Cache-Control或者Expires报头域。虽然如此,303 (See Other)响应可以用来引导客户代理来检索一个可缓存的资源。 参看15.1.3章关于安全的建议。 9.6 PUT 如果请求通过缓存或者请求指定了一个或多个当前缓存的实体,这些实体应该被丢弃。此方法的响应是不能缓存的。 POST和PUT请求根本的不同源自请求URI的含义不同。POST请求中的URI标识了处理附加实体的资源。那个资源可能是数据接受进程,一个其他协议的网关或者一个允许接收注解的单独的实体。相反,PUT请求里的URI指定了请求附带的实体——用户代理知道URI想要的并且服务端不能试图将请求应用到其它资源上。如果请求希望请求应用到不同的URI上,那么它必须发送一个301(永久转移)响应;关于是否要重定向请求可以由用户代理自己做出决定。 多个不同的URI可能会指定同一个资源。例如,一个主体可能会有一个标识“当前版本”的URI,这跟标识每个特定版本的URI是有区分的。这种情况下,一个普通URI上的PUT请求可能导致源服务定义一些其它的URI。 HTTP/1.1没有定义PUT方法如何影响一个源服务端的状态。 PUT请求必须遵守8.2章给出的消息传输要求。 除非领带指定一个特殊的实体报头,PUT请求里的实体报头应该应用到PUT所创建或修改的资源。 9.7 DELETE 如果响应包含描述状态的实体,成功的响应应该是200(OK),如果动作没有执行则返回202(接受的),或者如果动作已经执行但是响应里不包含实体则返回204(无内容)。 如果请求通过一个缓存或者请求URI标识了一个或多个当前的缓存实体,这些实体应该被丢弃。此方法的响应是不可缓存的。 9.8 TRACE TRACE允许客户端查看请求链的另一端接收到了什么以及是使用那些数据测试或者诊断信息。Via报头域的值有特殊的作用,它扮演了请求链的跟踪者的俄角色。使用Max-Forwards报头域允许客户端限制请求链的长度,这对测试一个无限循环投送信息的代理链是很有用的。 如果请求是有效的,响应应该将全部的请求信息包含来实体主体中,并且有一个“message/http”的 Content-Type。此方法的响应不能被缓存。 9.9 CONNECT 规范预留了一个CONNECT方法名让代理动态的切换为一个隧道(如 SSL隧道)。 10 状态码定义Status Code Definitions 10.1 消息1xx Informational 1xx 一个客户端必须准备在接受到正式的响应之前接受一个或多个1xx响应,即使客户端不期望一个100(继续)状态信息。未预期的1xx状态响应可以被用户代理忽略。 代理必须转递1xx响应,除非在客户端和客户端的连接被关闭,或者代理自身请求所产生的1xx响应。(例如:如果代理转递请求时添加一个“Expect:100-continue”域,那么它可以不必转递相应的100(继续)响应)。 10.1.1 继续100 Continue 10.1.2 切换协议101 Switching Protocols 协议应该在这样做有利的情况下进行切换。例如,切换为一个新的版本的HTTP协议比旧的协议有好处,而切换为一个实时的,同步的协议可能在处理使用此类功能的资源时更有利。 10.2 成功Successful 2xx 10.2.1 200 OK GET 响应返回一个对应于请求资源的实体。 HEAD 响应返回一对应于请求资源的实体报头域,没有消息主体。 POST 一个实体描述或保存动作的结果。 TRACE 一个包含服务接收的请求信息的实体。 10.2.2 创建201 Created 一个201响应可能含有一个ETag响应报头域标识请求变量创建的实体标记的当前值,参看14.19章。 10.2.3 接受202 Accepted 202响应是有意无委托的。它的目的是允许某些处理的请求(可能是一个批量处理会运行一天)不用要求用户代理到服务端的连接一直持续到处理完成。该响应的实体应该包含一个请求当前状态的标识,以及一个状态监控器的指示器或者一些用户可以判断请求何时被完成的估计。 10.2.4 非权威信息203 Non-Authoritative Information 10.2.5无内容 204 No Content 如果客户端是一个用户代理,它不应该改变它的会导致请求发送的文档视图。这个响应是有意为允许动作的输入发生时不会导致用户代理的活动文档视图哥改变,虽然一些新的或者更新的元信息应该被应用到当期用户代理的活动视图的文档上。 204响应不能包含消息体,因此总是由报头域后的空行终止。 10.2.6 重置内容205 Reset Content 10.2.7局部内容 206 Partial Content 响应必须包含以下报头域: l 一个Content-Range报头域(14.16章)标识想拥有包含的范围,或者一个多部分/字节范围的Content-Type包含每一部分的Content-Range域。如果一个Content-Length报头域出现在响应中,它的值必须与消息体中传输的OCTET的实际数目相匹配。 l Date l ETag 和(或)Content-Location,如果报头已经由200响应发送给同一个请求的话。 l Expires, Cache-Control, 和/或Vary,如果域值可能不同于以前发送的响应里的同一变量。 如果206响应是一个使用强缓存校验的If-Range请求的结果,响应不应该包含其他的实体报头域。如果响应是一个使用弱校验的If-Range请求的结果,响应必须不能包含其它的实体报头域;这避免了缓存实体主体和更新的报头的矛盾。否则的话,响应必须包含所有的实体报头,那些已经同200响应返回给同一个请求的报头。 一个缓存必须不能将一个206响应和以前缓存的内容相结合,如果Etag或者Last-Modified报头没有完全匹配,参看13.5.4章。 不支持Range和Content-Range报头的缓存必须不能缓存206响应。 10.3 重定向Redirection 3xx 注意:规范的早期版本推荐了一个5次重定向的最大次数。开发者应该知道可能有实现了固定限制的客户端。 10.3.1 多项选择300 Multiple Choices 除非是一个HEAD请求,响应应该包含有资源字符列表和位置的实体,由此客户或者客户代理可以选择最一个合适的。实体格式由报头域Content-Type给出的媒体类型指定。依托于格式和盈沪代理的能力,选择最合适的选项可以被自动执行。尽管如此,文档没有定义自动选择的标准。 如果服务有一个首选的表示选择,它应该在Location域里包含该表示的明确的URI;用户代理应该可以使用Location域值作为首选重定向。响应是可以缓存的,除非有其它的标识。 10.3.2 永久移动301 Moved Permanently 新的永久性的URI应该由响应中的Location域给出。除非请求方法是HEAD,响应的实体应该包含一个有执行新URI的超链接的简短的超文本注释。 如果在一个非GET或者HEAD请求的响应里接收到301状态码,用户代理必须不能自动重定向请求除非它可以被用户确认,因为这可能改变请求的初衷。 注意:当在接收到一个301状态码后自动重定向一个POST请求时,一下已有的HTTP/1.0用户代理可能错误的将它改变为一个GET请求。 10.3.3 302 Found 临时性的URI应该由响应的Location域给出。除非请求方法是HEAD,响应的实体应该包含一个有新URL超链接的简短的超文本描述。 如果一个非GET或HEAD请求的响应里接收到302状态码,用户代理不能自动重定向请求,除非用户确认,因为这可能会改变请求的初衷。 注意:RFC1945和RFC2068规定不允许客户端改变重定向请求的方法。不过,绝大多数的用户代理实现将302作为303响应对待,在Location域值上执行一个GET方法而忽略原来的请求方法。状态码303和307已经添加给那些确定客户端所期望反作用种类的服务端。 10.3.4 303 See Other 这个不同的URI应该由响应的Location域给出。除非请求方法是HEAD,响应实体应该包含一个有指向新URI的超链接的简单超文本注释。 注意:很多HTTP/1.1前的用户代理不识别303状态。如果与这种客户端进行交互,应该使用302状态码代替,因为大多数用户代理对302的反应类似于这里描述的303。 10.3.5 304 Not Modified 响应必须包含一下报头域: l Date,除非它的冗长是14.18.1章要求的。 如果一个无锁的源服务要求这些规则,并且代理和客户端添加自己的Date到一个没有该域的响应里,缓存应该做出合适的处理。 l Etag和/或Content-Location,如果报头已经由200响应发送给同一个请求。 Expires, Cache-Control, 和/或 Vary,如果域值可能不同于以前发送响应中的同一个变量。 如果条件GET使用了一个强缓存校验(13.3.3章),响应不应该包含其他的实体报头。否则(条件GET使用弱校验),响应不能包含其他实体报头;这预防了缓存实体主体和更新报头的矛盾。 如果一个304响应标识了一个当前没有被缓存的实体,缓存必须忽略响应并无条件的重发请求。 如果缓存使用一个接收到的304响应更新缓存实体,缓存必须更新实体来映射响应给出的新的域值。 10.3.6 使用代理305 Use Proxy 注意:RFC 2068没有明确305是要重发单一的请求,并且只能由源服务产生。不注意这些限制会产生重大的安全隐患 10.3.7不使用 306 (Unused) 10.3.8 307 临时重发Temporary Redirect 临时的URI应该由响应的Location域给出。除非请求方法是HEAD,响应的实体应该含有一个指向新URI的超链接的简短超文本描述,因为很多HTTP/1.1以前的用户代理不识别307状态。所以,描述应该包含一个用户重发基于新URI的原始请求是所必须的信息。 如果307状态码响应对应的请求方法不是GET或者HEAD,用户代理不能自动重发请求除非经由用户同意,因为这可能会改变请求的初衷。 10.4 客户端错误Client Error 4xx 如果客户端正在发送数据,使用TCP实现的服务端应该在关闭输入连接前,仔细确保客户端确认收到响应包含的包。如果客户端在关闭后继续向服务端发送数据,服务端的TCP栈将向客户端发送一个重置包,它将在客户端未确认的输入缓存被读取并在HTTP应用解析他们之前将其丢弃。 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 注意:HTTP/1.1服务端允许返回请求允许报头中不允许的响应。在有些情况中,这比返回406响应会更可取。我们鼓励用户代理检查响应中的报头来决定它是否可接收。 如果响应不能被接收,用户代理用该临时性停止接收更多的数据并询问客户决定下一步操作。 10.4.8 需要代理认证407 Proxy Authentication Required Basic and Digest Access Authentication” 有解释。 10.4.9 请求超时408 Request Timeout 10.4.10冲突 409 Conflict 冲突最可能发生在对PUT请求的响应里。例如,如果使用了版本控制并且PUT的实体包含了对某个资源的变更,而这又跟早一点(第三方)的请求所产生的相冲突,服务端可以使用409响应来标识出它不能完成请求。这种情况下,响应实体最好包含一个两个版本的差异的列表,其格式由响应的Content-Type来定义。 10.4.11 失效410 Gone 410响应主要用来通过通知接收者资源有意地无法获取并且服务拥有者要去删除资源的远程链接辅助web维护工作。这个事件通常在限制时间,增值服务以及个人所属资源不再在服务端站点工作时发生。没有必要标记所有的永久性不可用资源为“gone”或者将标记保持一段时间——那是留给服务端拥有者去决定的。 10.4.12 需要长度411 Length Required 10.4.13 预处理失败412 Precondition Failed 10.4.14 413 Request Entity Too Large 10.4.15 请求URI过长414 Request-URI Too Long 10.4.16不支持的媒体类型 415 Unsupported Media Type 10.4.17 请求范围不满足416 Requested Range Not Satisfiable 当这个状态码是返回给byte-range请求时,响应应该包含一个Content-Range实体报头域来指出所选资源的当前长度(参看14.16章)。这个响应不能使用multipart/byteranges内容类型。 10.4.18期望失败 417 Expectation Failed 10.5 服务器错误Server Error 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 注意:503状态码的存在并不是强制服务端在过载时使用它。某些服务可能希望简单的拒绝连接。 10.5.5 网关超时504 Gateway Timeout 注意:实现者应该注意:一些已有的代理在DNS查找超时时会返回400或者500。 10.5.6 不支持的HTTP版本505 HTTP Version Not Supported |
HTTP/1.1 协议 8-10
最新推荐文章于 2024-09-17 21:39:20 发布
HTTP/1.1 协议 8-10
2009年09月03日 星期四 上午 11:14