6

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

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

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

这里有什么技巧吗？这种不同的待遇会发生什么？

4

2 回答 2

7

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

10.3.2 301 永久移动

请求的资源已被分配一个新的永久 URI，并且任何将来对该资源的引用都应该使用返回的 URI 之一。如果可能，具有链接编辑功能的客户端应该自动将对 Request-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 以外的请求，则用户代理不得自动重定向
请求，除非用户可以确认，因为这可能会
改变发出请求的条件。

于 2012-11-02T22:05:18.137 回答
3

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

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

于 2015-09-15T01:16:52.353 回答