私の質問へのコメントに混乱/触発されました 検索エンジンはHTTPヘッダーフィールド「Content-Location」を尊重しますか? 、知りたいのですが、 Content-Location
HTTPのヘッダーフィールド は、その使用方法です。
GETリクエストに応答して、リクエストされたリソースに複数の表現が利用可能な場合、HTTPのContent-Locationを使用できます。複数の言語。返されるリソースの選択は、元のGETリクエストのAcceptヘッダーによって異なります。
通常、Content-Locationヘッダーで指定された場所は、元のリクエストのURIで指定された場所とは異なります。
PUTまたはPOSTリクエストに応じて、
Content-Location HTTPヘッダーは、HTTP GETへの応答に使用されたリソースの一意の場所を宣言することになっています(例:リクエストはGET /frontpage HTTP/1.1
、サーバーはHTTPヘッダーを追加できますContent-Location: http://domain.com/frontpage.english.msie-optimized
この特定の応答が後で必要になる場合は、元の場所がさまざまなものに依存する可能性があるため、指定された場所を使用する必要があることをユーザーエージェントに通知します。これは、「Vary
」ヘッダーで説明する必要があります。
ただし、HTTP Content-Locationヘッダーは、ブラウザー(ユーザーエージェント)によって処理が異なるため、実際の使用では問題があることに注意してください。 http://mail.python.org/pipermail/web-sig/2004-October/ 000985.html
これは、RFC 2616のセクション14.14で、「Content-Locationの値はエンティティのベースURIも定義する」と述べているためです。つまり、準拠するユーザーエージェントは、Content-Locationヘッダーを使用してフェッチされたドキュメントのBASE URLを計算します。これにより、フェッチされたドキュメントがBASE urlを定義しておらず、実際のフェッチされたURLとContent-Locationが十分に異なる場合、異なる相対URLが使用される可能性があります(URLの「ディレクトリ」/「パス」の部分は異なります)。
さらに、HTTP Content-Locationを使用する利点はまだわかりません(domain.com/news/latestのように、現在表示されているURLが不安定な場合に、永続的なブックマークの場所を示唆するためにこれを使用できることを望んでいましたが、そうではないようです)。
私の現在のアドバイスは、HTTPのContent-Locationを忘れていますが、MIME電子メールに使用できます。
Content-Locationエンティティヘッダーフィールドは、要求されたリソースのURIとは別の場所からエンティティにアクセスできる場合に、メッセージで囲まれたエンティティのリソースの場所を提供するために使用できます。
これは AtomPub(RFC 5023、セクション9.2) で使用されます:
作成要求にAtom Entry Documentが含まれ、サーバーからの後続の応答に、Locationヘッダーの文字ごとに一致するContent-Locationヘッダーが含まれている場合、クライアントは解釈を許可されます新しく作成されたエントリの完全な表現としての応答エンティティ。一致するContent-Locationヘッダーがない場合、クライアントは、返されたエンティティが作成されたリソースの完全な表現であると想定してはなりません。
興味がある場合は、RFC2557(: http://www.faqs.org/rfcs/rfc2557.html )で詳細な説明を確認してください。私は現在、これについてクラスのために書いています。それは少し古いですが、それでも関連性があります。