（技术文章翻译）HTTP 消息（四）

Servers and 100 Continue

如果一个服务器收到一条带有值为100-continue的expect 首部请求，它会用100 continue来响应或者一个错误的代码（请看table3-9），服务器不应该发送100 continue的状态码给客户端，如果客户端没有期望发送100-continue的话。然而，就像之前记录的，一些出错的服务器会这么做。

由于某种出错的原因，服务器在发送100-continue的状态码的时候，他已经收到了实体，。说明客户端已经决定继续发送数据了，那么服务器不应该发送这个状态码给客户端。当服务器读完请求之后，他仍然需要发送一些最终的状态码给客户端（他能够跳过100-continue 状态）

最终，如果服务器收到一个100-continue的请求，而且他在读取实体部分之前（因为他可能会出错），结束请求。并不是发送一条响应，并且关闭连接。这样会妨碍客户端接受响应（在第四章将会详细叙述）

Proxies and 100 Continue

如果代理从客户端收到了一调带有100-continue的请求。他需要做一些事情。如果代理知道下游服务器，（第6章将会讨论）与http1.1版本兼容，如果不知道下游服务器和那个版本的兼容。他都应该讲expect放入头部中，并向下转发，如果他知道下游服务器只能与http1.1版本兼容，那么就应该417响应。

如果一个代理决定于http1，1兼容，或者之前的版本，那么应该将100-continue，expect放入到请求中。如果他从服务器收到100-continue，就不应该将其转发给客户端。因为客户端也不知道应该拿他怎么办。

 代理维护一些有关下游服务器及其所支持的http版本的状态信息是有好处的。这样就可以处理那些带有100-continue的请求了              

200–299: Success Status Codes

当客户端发起一个请求，这些请求通常是成功的。服务器有一组表示成功的状态码。分别对应不同的内型。表3-7列出了这些状态码代表的含义

300–399: Redirection Status Codes

重定向状态码也告诉客户端使用代替位置的资源来替换它所感兴趣的资源。如果资源被移走了。一个重定向状态码和一个可选的localtion头部来告诉客户端资源已经被移走。浏览器就可以不打扰使用者的情况下，自动跳转到新的位置了。

图3-14

一些重定向的状态码，可以用来校验本地副本资源的位置和源服务器的资源位置。或者源服务器 上的资源是否被修改过。图3-15则展示了这个例子，客户端发送一个特殊的if-modified-since的头部消息，说明只读取在1997年10月之后被修改过的文档。但是返回一个304代码，说明在在这个日期之后该文档并没有被修改过。

图3-15

总之，在对那些包含了重定向状态码的非head请求进行响应时，最好要包括一个实体。在实体中包含描述信息和重定向的url参见图3-14的一个响应报文。表3-8列出了重定向代码的信息

table3-8

在表3-8中你嫩巩固注意到一个302,303，307之间有一些交叉。这些状态码的细微差别，源于http1.1和http1.0之间对这些状态码处理的差异。

当http1.0客户端发送一个post方法的请求，接收到一个302的重定向状态码，在响应中。他讲得到这个重定向url并且发送一个get请求，代替那个post请求，而不像原始的请求那样，直接发送post请求。困惑来自于http1.1，在http1.1规范中使用303状态码

来处理这种相似的行为，（服务器发送303状态码，重定向后，发送一个get请求来代替）

为了避开这个问题。在http1.1中用307状态码来代替302状态码，这样服务I器就可以将302状态码保留起来为http1.1客户端使用了。这样服务器需要查看客户端http版本之后才能放入响应的状态码到响应消息中了。

400–499: Client Error Status Codes

有时一个客户端发送一些服务器无法处理的东西，比如一种错误格式的message消息。或者是请求一个不存在的url，我们在浏览器通常会看到一个404的状态码，这是因为服务器告诉我们，我们请求ide资源不存在了。大部分错误将会被你的浏览器处理。只有一小部分没有被出列，像

404，还是通过浏览器展现给用户，在表3-9中将会展示这些错误状态码的细节

500–599: Server Error Status Codes

有时客户端会发送一个有效的request请求，但是服务器内部也有可能会出现错误。这坑内是客户端碰上了服务器的缺陷。从而导致出错。

代理尝试代表客户端和服务器进行交流，也常常会出错。代理会发布5XX的错误状态码来描述可能会出现的问题，表3-10定义了这些服务器错误的状态码。

table3-10

Headers

首部和方法配合工作，共同决定了客户端和服务器能做什么事情，本节快速讲解了，在http1.1中对首部的一些详细描述。在请求和响应报文中都可以用首部来提供信息，有些首部是某种报文专用的，有些则比较通用一些。

在这里主要将首部分为5种类型

General headers

这些是客户端和服务器之间都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些通用的功能，例如，日期，是一个通用首部，每一端都已用它来说明报文构建的时间。

Date: Tue, 3 Oct 1974 02:16:00 GMT

Request headers

请求首部，从名字就可以看出，请求首部是请求报文中特有的。他们为服务器提供一些额外的信息。例如客户端将会接受什么样的数据，例如，accept header告诉服务器我们需要接受的数据类型为任意媒体类型

Accept: */*

Response headers

响应首部，响应消息有自己的首部集，以便为客户端提供信息，例如客户端现在在与那种类型的服务器进行交互。将会将这种消息，通过响应首部告诉给客户端

Server: Tiki-Hut/1.0

Entity headers

实体首部，实体首部是指应对实体主体部分的首部，例如可以用实体首部来告诉客户端，主体的类型是什么，例如通过content-type来告诉应用程序是text/html文件类型，编码为iso-latin-1

Content-Type: text/html; charset=iso-latin-1

Extension headers

扩展首部，不是标准的首部，由应用程序开发者自己创建。还没有添加到http规范中。