HTTP状态码详解之101

参考RFC2616,10.1.2节

服务器理解并愿意服从客户端含有Upgrade信息头字段的请求,以改变当前连接使用的应用层协议。
服务器在响应101状态码的最后空行后,将立即切换到响应头中定义的Upgrade字段的协议。

协议只有在对其有益的前提下才应该切换。例如,切换到一个新的HTTP版本比用老版本更有益,切换到一个实时的、同步的协议在使用这些特性传送资源会更优越。

HTTP状态码详解之100

参考RFC2616,10.1.1节和8.2.3节

一、1xx类的状态码
1xx的状态码表示一个临时的响应,仅由状态行和可选头构成,由空行结尾。对该类状态码,不需要头部。由于HTTP1.0没有定义任何1xx系列的状态码,所以服务器禁止向HTTP1.0的客户端响应1xx状态码,除非出于实验目的。
客户端必须准备好在正常响应前接收1个或多个1xx状态的响应,即使客户端没有期望一个100(continue)状态码信息。非预期的1xx状态码响应可以被忽略。
代理必须转发1xx响应,除非代理和客户端之间的连接关闭或代理本身的请求导致了1xx的响应(例如,如果代理添加“Expect: 100-continue”在请求头域中,那么它就不该转发对应的100响应)。

二、100(Continue)状态码
客户端应该继续它的请求。这个过渡的响应用于告知客户端,请求的初始部分已经被服务器收到,并且没有被服务器拒绝。客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应。服务器必须在请求完成后发送一个最终的响应。
100状态码的用途主要是,允许客户端发送带请求体的请求前,判断服务器是否愿意接收请求(通过请求头)。在某些情况下,如果服务器在不看请求体就拒绝请求时,客户端就发送请求体是不恰当的或低效的。

对HTTP1.1的客户端的要求:
如果客户端将在发送请求体之前等待100状态码的响应,则它必须发送一个Expect请求头,值为“100-continue”。
如果客户端不打算发送请求体,就禁止发送值为“100-continue”的Expect请求头。

由于早起实现的原因,协议允许一些有歧义的情况,例如客户端可以发送“Expect: 100-continue”而不接收417或100状态码。所以,客户端发送这个头部时,不应该无限期的等待100状态码返回而不发送请求体。

对HTTP1.1的服务器的要求:
当接收到包含Expect的值为“100-continue”的请求头时,服务器必须响应100状态码并继续读取输入流,或者响应一个最终的状态码。服务器禁止在发送100状态码响应前等待请求体。如果返回了一个最终的状态码,它可以终止传输连接或者可以继续读剩余的请求并丢弃,但禁止处理请求。
如果客户端使用HTTP1.0或更低版本的协议或者没有在请求头中发送Expect信息,则服务器不应该发送100状态码响应。但有个例外:为了兼容RFC2068,服务器可以发送100状态码响应给HTTP1.1的PUT或POST请求,即使它们不包含Expect请求头。这个例外只对HTTP1.1的请求有效,不包括其他任何版本。
服务器可以在已经接到部分或全部请求体后,不发送100状态码的响应。
发送100状态码响应的服务器必须在收到并处理请求体后,发送一个最终响应码,除非连接过早的中断。
如果服务器收到了一个不包含请求头Expect的值为“100-continue”的请求,且请求包含请求体,并且服务器在读取完整请求前响应了最终状态码,则服务器在读取全部请求前不应该关闭传输连接。否则,客户端可能不能可靠的接收响应的信息。但该需求不会限制服务器保护自身受到攻击或接到一些非法的恶意客户端请求。

对于HTTP1.1代理的要求:
如果代理包含一个Expect值为“100-continue”的请求头的请求,并且它知道下一跳的服务器支持HTTP1.1及更高版本的协议,或者不知道下一跳服务器的HTTP版本,它就必须转发请求包含Expect头域。
如果代理知道下一跳服务器是HTTP1.0以及更低版本,它就禁止转发这个请求,并必须返回一个417状态码。
代理应该维护一个最近联系的下一跳服务器的HTTP版本缓存记录。
代理禁止向一个来自HTTP1.0或更早版本的客户端且不包含Expect值为“100-continue”的请求转发100状态码响应。这个要求会覆盖转发1xx响应的总体规则。