标签：也会 重定向 文件上传 响应头 temp 空闲 use agent 频繁
100 Continue :post上传数据使用
100-continue 是用于客户端在发送 post 数据给服务器时，征询服务器情况，看服务器是否处理 post 的数据,如果不处理，客户端则不上传 post 是数据，反之则上传。在实际应用中，通过 post 上传大数据时，才会使用到 100-continue 协议。
客户端策略 :
{“Expect”:”100-continue”}Expect:100-continue消息后，在 timeout 时间内无响应，Client 需要立马上传 post 数据。服务端策略
101 Switching Protocol: websocket长连接使用
长连接状态，web端的话使用html5的websocket会出现,可以看出长时间pending,一直处于连接状态（用来做通讯类的)
102 Processing: 正在处理
表示请求已经被接受,正在处理,但是目前没有可用的相应返回,可能表示处理还没完成?
少有实现
200 OK:请求已成功
请求已成功，请求所希望的响应头或数据体将随此响应返回。
有可能是expires缓存，不请求服务器，此时size == from cache
不同请求方式对于请求成功的意义如下:
PUT和 DELETE的请求成功通常并不是响应200 OK```的状态码而是 204 No Content 表示无内容(或者 201 Created表示一个资源首次被创建成功)。
201 Created: 请求成功
是对200的细化,是一个代表成功的应答状态码，表示请求已经被成功处理，并且创建了新的资源。新的资源在应答返回之前已经被创建。同时新增的资源会在应答消息体中返回，其地址或者是原始请求的路径，或者是?Location?首部的值
常规使用场景是作为?PUT请求的返回值
202 Accepted: 收到请求,异步处理
表示服务器端已经收到请求消息，但是尚未进行处理。但是对于请求的处理确实无保证的，即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形。
203 Non-Authoritative Information: 被代理服务器修改
表示请求已经成功被响应，但是获得的负载与源头服务器的状态码为 200 (OK)的响应相比，经过了拥有转换功能的 proxy （代理服务器）的修改。
204 No Content: 缓存相关无更新
表示目前请求成功，但客户端不需要更新其现有页面。204 响应默认是可以被缓存的。在响应中需要包含头信息 ETag。
使用惯例是，在 PUT 请求中进行资源更新，但是不需要改变当前展示给用户的页面，那么返回 204 No Content。如果新创建了资源，那么返回 201 Created 。如果页面需要更新以反映更新后的资源，那么需要返回 200 。
205 Reset Content
通知客户端重置文档视图，比如清空表单内容、重置 canvas 状态或者刷新用户界面。
206 Partial Content: range相关相应
表示请求已成功，并且主体包含所请求的数据区间，该数据区间是在请求的 Range 首部指定的。
如果只包含一个数据区间，那么整个响应的 Content-Type 首部的值为所请求的文件的类型，同时包含 Content-Range 首部。如果包含多个数据区间，那么整个响应的 Content-Type 首部的值为 multipart/byteranges ，其中一个片段对应一个数据区间，并提供 Content-Range 和 Content-Type 描述信息。
300 Multiple Choice:多个可选择的重定向
表示重定向的响应状态码，表示该请求拥有多种可能的响应。用户代理或者用户自身应该从中选择一个。由于没有如何进行选择的标准方法，这个状态码极少使用。
301 Moved Permanently:永久重定向
说明请求的资源已经被移动到了由 Location 头部指定的url上，是固定的不会再改变。搜索引擎会根据该响应修正。
尽管标准要求浏览器在收到该响应并进行重定向时不应该修改http method和body，但是有一些浏览器可能会有问题。所以最好是在应对GET 或 HEAD 方法时使用301，其他情况使用308 来替代301。
302 Found:临时重定向
表明请求的资源被暂时的移动到了由Location 头部指定的 URL 上。浏览器会重定向到这个URL， 但是搜索引擎不会对该资源的链接进行更新.
推荐仅在响应 GET 或 HEAD 方法时采用 302 状态码，而在其他时候使用 307 Temporary Redirect 来替代
在确实需要将重定向请求的方法转换为 GET的场景下，可以使用 303 See Other。例如在使用 PUT 方法进行文件上传操作时，需要返回确认信息（例如“你已经成功上传了xyz”）而不是上传的资源本身，就可以使用这个状态码。
303 See Other:post和put用重定向
重定向状态码，通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。
304 Not Modified:缓存相关
说明无需再次传输请求的内容，也就是说可以使用缓存的内容。这通常是在一些安全的方法（safe），例如GET 或HEAD 或在请求中附带了头部信息： If-None-Match 或If-Modified-Since。
如果是 200 OK ，响应会带有头部 Cache-Control, Content-Location, Date, ETag, Expires，和 Vary.表明更新过一次资源
305 Use Proxy:需要代理访问
被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。
307 Temporary Redirect:临时重定向
表示重定向的响应状态码，说明请求的资源暂时地被移动到 Location 首部所指向的 URL 上。原始请求中的请求方法和消息主体会在重定向请求中被重用 .
在确实需要将重定向请求的方法转换为 GET 的场景下，可以考虑使用 303 See Also 状态码。例如在使用 PUT 方法进行文件上传操作时，需要返回确认信息（例如“你已经成功上传了xyz”）而不是上传的资源本身，就可以使用这个状态码。
状态码 307 与 302 之间的唯一区别在于，当发送重定向请求的时候，307 状态码可以确保请求方法和消息主体不会发生变化。当响应状态码为 302 的时候，一些旧有的用户代理会错误地将请求方法转换为 GET：使用非 GET 请求方法而返回 302 状态码，Web 应用的运行状况是不可预测的；而返回 307 状态码时则是可预测的。对于 GET 请求来说，两种情况没有区别。
308 Permanent Redirect:永久重定向
表示重定向的响应状态码，说明请求的资源已经被永久的移动到了由 Location 首部指定的 URL 上。浏览器会进行重定向，同时搜索引擎也会更新其链接
在重定向过程中，请求方法和消息主体不会发生改变，然而在返回 301 状态码的情况下，请求方法有时候会被客户端错误地修改为 GET 方法。
400 Bad Request:语义或参数错误
表示由于语法无效，服务器无法理解该请求。 客户端不应该在未经修改的情况下重复此请求。
401 Unauthorized:用户未验证
代表客户端错误，指的是由于缺乏目标资源要求的身份验证凭证，发送的请求未得到满足。 这个状态码会与 WWW-Authenticate 首部一起发送，其中包含有如何进行验证的信息。 这个状态类似于 403， 但是在该情况下，依然可以进行身份验证。
402 Payment Required
响应码保留以便将来使用，创造此响应码的最初目的是用于数字支付系统，然而现在并未使用
403 Forbidden:拒绝执行
客户端错误，指的是服务器端有能力处理该请求，但是拒绝授权访问。 这个状态类似于 401，但是进入该状态后，不能再继续进行验证。该访问是永久禁止的，并且与应用逻辑密切相关（例如不正确的密码）。
404 Not Found:资源不存在
请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
405 Method Not Allowed:请求方法不存在
表明服务器禁止了使用当前 HTTP 方法的请求。需要注意的是，GET 与 HEAD 两个方法不得被禁止，当然也不得返回状态码 405。
鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。
406 Not Acceptable:和语言以及编码相关
服务器端无法提供与 Accept-Charset 以及 Accept-Language 消息头指定的值相匹配的响应。 在实际应用中，这个错误状态码极少使用：不是给用户返回一个晦涩难懂（且难以更正）的错误状态码，而是将相关的消息头忽略，同时给用户提供一个看得见摸得着的页面。这种做法基于这样一个假设：即便是不能达到用户十分满意，也强于返回错误状态码。
407 Proxy Authentication Required:
与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。
这个状态码会与 Proxy-Authenticate 首部一起发送，其中包含有如何进行验证的信息。
408 Request Timeout:
请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 .
表示服务器想要将没有在使用的连接关闭。一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下。 服务器应该在此类响应中将 Connection 首部的值设置为 "close"，因为 408 意味着服务器已经决定将连接关闭，而不是继续等待。 这类响应出现的比较频繁，源于一些浏览器——例如 Chrome, Firefox 27+, 或者 IE9 等——使用 HTTP 协议中的预连接机制来加速上网体验。同时应该注意到，某些服务器会直接关闭连接，而不发送此类消息。
409 Conflict:冲突
由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。
冲突最有可能发生在对 PUT 请求的响应中。例如，当上传文件的版本比服务器上已存在的要旧，从而导致版本冲突的时候，那么就有可能收到状态码为 409 的响应。
410 Gone:
被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用 404 状态码。除非额外说明，否则这个响应是可缓存的。
411 Length Required:
服务器拒绝在没有定义?Content-Length?头的情况下接受请求。在添加了表明请求消息体长度的有效?Content-Length?头之后，客户端可以再次提交该请求。
属于客户端错误，表示由于缺少确定的Content-Length 首部字段，服务器拒绝客户端的请求。 注意，按照规范，当使用分块模式传输数据的时候， Content-Length 首部是不存在的，但是需要在每一个分块的开始添加该分块的长度，用十六进制数字表示。
412 Precondition Failed:
服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。
意味着对于目标资源的访问请求被拒绝。这通常发生于采用除 GET 和 HEAD 之外的方法进行条件请求时，由首部字段 If-Unmodified-Since 或 If-None-Match 规定的先决条件不成立的情况下。这时候，请求的操作——通常是上传或修改文件——无法执行，从而返回该错误状态码。
413 Payload Too Large:
服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的，服务器应当返回一个?Retry-After?的响应头，以告知客户端可以在多少时间以后重新尝试。
414 URI Too Long:
请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。
415 Unsupported Media Type:
表示服务器由于不支持其有效载荷的格式，从而拒绝接受客户端的请求。
格式问题的出现有可能源于客户端在 Content-Type 或 Content-Encoding 首部中指定的格式，也可能源于直接对负载数据进行检测的结果。
416 Requested Range Not Satisfiable:
请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。
意味着服务器无法处理所请求的数据区间。最常见的情况是所请求的数据区间不在文件范围之内，也就是说，Range 首部的值，虽然从语法上来说是没问题的，但是从语义上来说却没有意义。
遇到这一错误状态码的时候，浏览器一般有两种策略：一种是终止操作，例如，一项中断的下载操作被认为是不可恢复的；另外一种是再次请求整个文件。
417 Expectation Failed:
表示客户端错误，意味着服务器无法满足 Expect 请求消息头中的期望条件。
Expect 是一个请求消息头，包含一个期望条件，表示服务器只有在满足此期望条件的情况下才能妥善地处理请求。 规范中只规定了一个期望条件，即 Expect: 100-continue, 对此服务器可以做出如下回应： 100 如果消息头中的期望条件可以得到满足，使得请求可以顺利进行的话， 417 (Expectation Failed) 如果服务器不能满足期望条件的话；也可以是其他任意表示客户端错误的状态码（4xx）。 例如，如果请求中 Content-Length 的值太大的话，可能会遭到服务器的拒绝。 常见的浏览器不会发送 Expect 消息头，但是其他类型的客户端如cURL默认会这么做
418 I‘m a teapot:
表示服务器拒绝冲泡咖啡，因为它是一个茶壶。 这个错误是超文本咖啡壶控制协议的参考，这是1998年愚人节的笑话。
429 Too Many Requests:
用户在给定的时间内发送了太多请求（“限制请求速率”）。
431 Request Header Fields Too Large:
服务器不愿意处理请求，因为它的 请求头字段太大（ Request Header Fields Too Large）。 请求可以在减小请求头字段的大小后重新提交。
500 Internal Server Error
示服务器端错误的响应状态码，意味着所请求的服务器遇到意外的情况并阻止其执行请求。
这个错误代码是一个通用的“全方位”响应代码。通常服务器管理员对于类似于 500 这样的错误会更加详细地记录相关的请求信息来防止以后同样错误的出现。
501 Not Implemented:
请求方法不被服务器支持且无法被处理。只有GET和HEAD是要求服务器支持的，它们必定不会返回此错误代码。
502 Bad Gateway:
此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
503 Service Unavailable:
服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。 请注意，与此响应一起，应发送解释问题的用户友好页面。 这个响应应该用于临时条件和 Retry-After：如果可能的话，HTTP头应该包含恢复服务之前的估计时间。 网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。
504 Gateway Timeout:
表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应。
505 HTTP Version Not Supported:
服务器不支持请求中所使用的HTTP协议版本。
511 Network Authentication Required
表示客户端需要通过验证才能使用该网络。
该状态码不是由源头服务器生成的，而是由控制网络访问的拦截代理服务器生成的。
Expires http/1.0中定义的header，是最基础的浏览器缓存处理，表示资源在一定时间内从浏览器的缓存中获取资源，不需要请求服务器获取资源，从而达到快速获取资源，缓解服务器压力的目的。
Cache-Control：设置请求响应链上所有的缓存机制必须遵守的指令 Cache-Control: no-cache
| 操作 | 是否会刷新 |
|---|---|
| 打开新窗口 | 如果指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗口访问时都会重新访问服务器。而如果指定了max-age值,那么在此值内的时间里就不会重新访问服务器,例如：Cache-control: max-age=5 表示当访问此网页后的5秒内不会去再次访问服务器. |
| 在地址栏回车 | 如果值为private或must-revalidate,则只有第一次访问时会访问服务器,以后就不再访问。如果值为no-cache,那么每次都会访问。如果值为max-age,则在过期之前不会重复访问。 |
| 按后退按扭 | 如果值为private、must-revalidate、max-age,则不会重访问,而如果为no-cache,则每次都重复访问. |
| 按刷新按扭 | 无论为何值,都会重复访问. |
Expires 与 Cache-Control的max-age
Expires采用的是服务器时间来确定何时超时，但是当服务器与客户端存在时间差很大的时候（客户端时间不准）那么Expires的缓存就会不精确
Cache-Control的max-age则采用的是更新间隔，因此比Expires更加精确一些。
所以在HTTP 1.1版开始，使用Cache-Control: max-age替代。
注意：如果max-age和Expires同时存在，则被Cache-Control的max-age覆盖。
Last-Modified 在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是客户端请求的资源，同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间。客户端第二次请求此URL时，根据HTTP协议的规定，浏览器会向服务器传送If-Modified-Since报头，询问该时间之后文件是否有被修改过。如果服务器端的资源没有变化，则自动返回 HTTP 304（Not Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。精确到秒。
if-modified-since 服务器将缓存文件的缓存时间与请求本地时间戳比较后，如果发现没有改认为此资源可以继续使用，而且不用再次通知客户端被称为 not-modified 所以not- modified的响应码是304 只要客户端收到304响应码就认为没有改变，那么它的缓存将会继续使用，由于发一次新请求就意味着页面缓存时长又可以继续使用。
但是，当网站内容的修改频度非常高，因为有些内容是动态生成的 以毫秒级别来管理，但是Last-Modified 配合Modified-Since只能精确到秒，因此会存在一个不一致的行为
Etag 根据文件名和修改时间生成一个字符串，可以标识精确的修改时间到毫秒。配合If-none-match。代替Last-Modified/if-modified-since。但其实两者本质是相同的。
在web服务器只有一台的情况，请求内容的唯一性可以由Etag来确定，但是如果是多台web服务器在负载均衡设备下提供对外服务，尽管各web服务器上的组件内容完全一致，但是由于在不同的服务器上inode是不同的，因此对应生成的Etag也是不一样的。在这种情况下，尽管请求的是同一个未发生变化的组件，但是由于Etag的不同，导致Apache服务器不再返回「“304 Not Modified”，而是返回了200 OK和实际的组件内容（尽管事实上内容不曾发生变化），大大浪费了带宽。
因此分布式中ETAG的生成不能依赖于底层。否则会出现ETAG不一致的情况。
Last-Modified、Etag和Expires
使用Last-Modified标识由于在资源未修改时返回的response内容为空，可以节省一点带宽，但是还是逃不掉发一个HTTP请求出去，需要浏览器连接一次服务器端。
而Expires标识却使得浏览器干脆连HTTP请求都不用发，但是当用户使用F5或者点击Refresh按钮的时候，就算URI设置了Expires，浏览器一样也会发一个HTTP请求给服务器端，所以，Last-Modified还是要用的，而且要和Expires一起用。
标签：也会 重定向 文件上传 响应头 temp 空闲 use agent 频繁
原文地址：https://www.cnblogs.com/perfy576/p/9347699.html
