302与303的例子

您链接到的页面上的描述似乎是对其预期目的的相当描述：

302redirect表示redirect是临时的 – 客户端应该在以后的请求中检查原始URL。

303redirect意味着将POST请求redirect到GET资源（否则，客户端会假定新位置的请求方法与原始资源的请求方法相同）。

如果您将客户端redirect为Web应用程序的一部分，但希望他们始终从Web应用程序开始（例如URL缩写），则302redirect似乎有意义。 303redirect用于从客户端接收POST数据（例如表单提交），并且您希望将它们redirect到使用GET而不是POST （例如，标准页面请求）进行检索的新网页。

但是从状态码定义中看到这个注释 – 大多数客户端对于302或者303都会做同样的事情：

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. 

有四种不同的redirecttypes（当前）。 本来只有两个，但大多数客户端实现了302redirect不正确，所以增加了两个，以澄清两个不同的可能行为之间的差异接收302。

您链接的RFC在302redirect部分陈述了这一点：

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. 

1. 301redirect是永久redirect。 它是可caching的，并且此URL的任何书签都应更新为指向新的URL。
2. 302redirect是临时redirect。 它不是默认caching的，每次都应该重新请求（但是你可以用caching头来重写）。 后续请求应使用与原始请求相同的方法（POST，GET，CONNECT，PUT，DELETE等），除了GET和HEAD请求之外，客户端在提出请求之前应提示用户。 这是客户错误的部分，不pipe原始方法如何，他们中的大多数都会将后续请求的方法更改为GET。
3. 303redirect与302相同，只是后续请求现在明确地改为GET请求，不需要确认。
4. 307redirect与302相同，只是后续请求现在与原始请求明显相同，必须从用户那里获取除GET和HEAD之外的请求方法的确认。

老客户可能不了解303redirect。 任何使HTTP / 1.1请求的东西都应该理解303响应。

有可能将300个和305个响应视为redirect，这意味着有六种不同的types。

使用redirecttypes（301,302,303 …）对search引擎如何索引和排列内容有很大的影响。 一些蜘蛛甚至可能拒绝临时redirect的内容。 详情可以在各种SEO文献中find…