6

PHP で URL 短縮プロジェクトに取り組んでいます。私たちは 301 HTTP リダイレクトを使用しており、リンクの訪問を自然に追跡しています。しかし、何か奇妙なことがあります:

URLを短縮してブラウザで通過した後、最初の訪問のみが追跡され、他のリクエストはサーバーに送信されず、直接宛先URLに送信されるようです.（これは後のブラウザキャッシュだと思います.一度試してください）。しかし ：

bitlyのような同様のサービスを試してみると、扱いが異なります。同じブラウザーでの同じリクエストのいくつかは、ビット単位の訪問追跡で追跡されます (実際には、それらの複数であり、理由がわかりません。ロジックが表示されません)。また、301 リダイレクトも使用します。(左)ブラウザ ウィンドウの下部に「waiting for bit.ly...」と表示される場合とそうでない場合があります。実際にはランダムに表示されます)。

ここにトリックは含まれていますか？この異なる御馳走はどうなりますか？

4

2 に答える 2

7

HTTP 仕様を読んでください。応答301は、要求されたリソースがリダイレクト先の新しい URL に永続的に移動したため、元の URL を使用してはならないことをブラウザーに伝えます。

10.3.2 301 恒久的に移動

要求されたリソースには新しい永続的な URI が割り当てられており、このリソースへの今後の参照では、返された URI のいずれかを使用する必要があります。リンク編集機能を持つクライアントは、可能であれば、Request-URI への参照をサーバーから返された 1 つ以上の新しい参照に自動的に再リンクする必要があります。特に明記しない限り、この応答はキャッシュ可能です。

新しい永続的な URI は、応答の Location フィールドで指定する必要があります。リクエスト メソッドが HEAD でない限り、レスポンスのエンティティには 、新しい URI
へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。

GET または HEAD 以外のリクエストへの応答として 301 ステータス コードを受信した場合 、ユーザーが確認できない限り
、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません 。これにより、リクエストが発行された条件が変更される可能性があるためです。

  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
へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。

GET または HEAD 以外のリクエストに応答して 302 ステータス コードを受信した場合 、ユーザーが確認できない限り
、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません 。これにより、リクエストが発行された条件が変更される可能性があるためです。

  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
応答はキャッシュしてはなりませんが、2 番目の
(リダイレクトされた) 要求に対する応答はキャッシュ可能かもしれません。


応答の Location フィールドで別の URI を指定する必要があります (SHOULD) 。リクエスト メソッドが 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 フィールドで指定する必要があります。 HTTP/1.1 より前の多くのユーザー エージェントは 307 ステータスを理解していないため、リクエスト メソッドが HEAD でない限り、
レスポンスのエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト メモを含める必要があります。したがって、メモには、ユーザー が新しい URI で元の要求を繰り返すために必要な情報を含める必要があります。



GET または HEAD 以外のリクエストに応答して 307 ステータス コードを受信した場合 、ユーザーが確認できない限り
、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません 。これにより、リクエストが発行された条件が変更される可能性があるためです。

于 2012-11-02T22:05:18.137 に答える
3

私のコメントを書き留めるためだけに..

これには、キャッシュ制御ヘッダーも役割を果たします。curl または firebug の永続的なトラッキングで確認すると、場所の前にキャッシュ コントロール ヘッダーが表示されます。bitly は、ユーザーが 90 秒後にリンクをクリックすると、連絡を受けるように構成されています。

于 2015-09-15T01:16:52.353 に答える