url缩短器301重定向理解

Question

我们正在用 PHP 开发一个 URL 缩短器项目。我们使用 301 HTTP 重定向并自然地跟踪我们的链接访问。但有一些奇怪的事情：

我们缩短了一个网址，通过浏览器通过后，只跟踪了第一次访问，好像没有其他请求发送到我们的服务器，直接转到目标网址。（我认为这是浏览器缓存之后一试）。但 ：

当尝试使用类似bitly 的服务时，它有不同的待遇。相同浏览器上的一些相同请求在位访问跟踪中被跟踪（实际上不止一个，我不明白为什么，我没有看到任何逻辑），同时它们也使用 301 重定向。（在左边浏览器窗口的底部有时会写“waiting for bit.ly...”，有时不会，实际上是随机的）。

这里包含任何技巧吗？这种不同的待遇会发生什么？

Answer 1

阅读HTTP 规范。一个301响应告诉浏览器所请求的资源已permanantly移动到被重定向到新的URL，并且不应该再使用原来的网址：

10.3.2 301 永久移动

被请求的资源已经被分配了一个新的永久 URI，以后对该资源的任何引用都应该使用返回的 URI 之一。在可能的情况下，具有链接编辑功能的客户端应该自动将请求 URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则
响应的实体应该包含一个带有指向
新 URI的超链接的短超文本注释。

如果收到 301 状态代码以响应
GET 或 HEAD 以外的请求，则用户代理
不得自动重定向请求，除非用户可以确认，因为这可能会
更改发出请求的条件。

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

对于您正在尝试一下，尝试使用302，303或307代替。

10.3.3 302 发现

请求的资源临时驻留在不同的 URI 下。
由于有时可能会更改重定向，因此客户端应该继续使用 Request-URI 来处理未来的请求。
如果由 Cache-Control 或 Expires 标头
字段指示，则此响应仅可缓存。

临时 URI 应该由
响应中的 Location 字段给出。除非请求方法是 HEAD，否则
响应的实体应该包含一个带有指向
新 URI的超链接的短超文本注释。

如果收到 302 状态代码以响应
除 GET 或 HEAD 之外的请求，则用户代理
不得自动重定向请求，除非用户可以确认，因为这可能会
更改发出请求的条件。

  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.

.

10.3.4 303 见其他

对请求的响应可以在不同的 URI 下找到，并且应该使用该资源的 GET 方法检索。此方法的
存在主要是为了允许 POST 激活脚本的输出
将用户代理重定向到选定的资源。新的 URI 不是
原始请求资源的替代引用。303
响应不能被缓存，但对第二个
（重定向）请求的响应可能是可缓存的。

不同的 URI 应该由
响应中的 Location 字段给出。除非请求方法是 HEAD，否则
响应的实体应该包含一个带有指向
新 URI的超链接的短超文本注释。

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

.

10.3.8 307 临时重定向

请求的资源临时驻留在不同的 URI 下。
由于有时可能会更改重定向，因此客户端应该
继续使用 Request-URI 来处理未来的请求。
如果由 Cache-Control 或 Expires 标头
字段指示，则此响应仅可缓存。

临时 URI 应该由
响应中的 Location 字段给出。除非请求方法是 HEAD，否则
响应的实体应该包含一个带有指向
新 URI的超链接的短超文本注释，因为许多 HTTP/1.1 之前的用户代理不
理解 307 状态。因此，注释应该包含
用户
在新 URI上重复原始请求所需的信息。

如果收到 307 状态代码以响应
GET 或 HEAD 以外的请求，则用户代理
不得自动重定向请求，除非它可以得到用户的确认，因为这可能会
改变发出请求的条件。

Answer 2

只是为了记下我的评论..

缓存控制标头也在这方面发挥了作用。如果您使用curl或firebug持久跟踪进行检查，您可以在该位置之前看到缓存控制标头。bitly 配置为如果用户在 90 秒后单击链接，则会回复联系。