url shortener 301重定向理解

Question

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

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

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

这里有任何技巧吗？这种不同的治疗方法发生了什么？

Answer 1

阅读HTTP specification。 301响应告诉浏览器所请求的资源已经永久移动到重定向到的新URL，并且不应再使用原始URL：

  

10.3.2 301永久移动

     

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

     

新的永久URI应该由位置字段给出   响应。除非请求方法是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应该由中的位置字段给出   响应。除非请求方法是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应该由中的位置字段给出   响应。除非请求方法是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应该由中的位置字段给出   响应。除非请求方法是HEAD，否则为实体   响应应该包含一个带有超链接的短超文本注释   新的URI，因为许多pre-HTTP / 1.1用户代理没有   了解307的状态。因此，说明应该包含
  用户重复原始请求所必需的信息   新的URI。

     

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

Answer 2

请记下我的评论..

缓存控制标头也起到了作用。如果使用curl或firebug持久性跟踪进行检查，则可以在该位置之前查看缓存控制标头。如果用户在90秒后点击链接，则将bitly配置为联系回来。