42

私の質問へのコメントに混乱/触発されました検索エンジンは HTTP ヘッダー フィールド「Content-Location」を尊重しますか? Content-Location、 HTTP のヘッダー フィールドの正確な目的とその使用方法を知りたいです。

4

4 に答える 4

18

GETリクエストに応答して、リクエストされたリソースに複数の表現が利用可能な場合、たとえば複数の言語がある場合、HTTPのContent-Locationを使用できます。返されるリソースの選択は、元のGETリクエストのAcceptヘッダーによって異なります。

通常、Content-Locationヘッダーで指定された場所は、元のリクエストのURIで指定された場所とは異なります。

PUTまたはPOSTリクエストに応答して、

于 2009-01-15T20:25:53.947 に答える
13

Content-Location HTTPヘッダーは、HTTP GETへの応答に使用されたリソースの一意の場所を宣言することになっています（たとえば、要求があった場合、サーバーは、この特定の応答が後で必要になった場合に、提供された場所をユーザーエージェントに通知GET /frontpage HTTP/1.1するHTTPヘッダーを追加できます元の場所はさまざまなものに依存する可能性があるため、使用する必要があります。これは、「」ヘッダーで説明する必要があります。Content-Location: http://domain.com/frontpage.english.msie-optimizedVary

ただし、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電子メールに使用することもできます。

于 2011-06-27T10:07:23.260 に答える
9

RFC 2616のセクション14.14には、次のように記載されています。

Content-Locationエンティティヘッダーフィールドは、要求されたリソースのURIとは別の場所からエンティティにアクセスできる場合に、メッセージで囲まれたエンティティのリソースの場所を提供するために使用できます。

これはAtomPub（RFC 5023、セクション9.2）で使用されます：

作成要求にAtomEntryDocumentが含まれ、サーバーからの後続の応答にLocationヘッダーが文字ごとに一致するContent-Locationヘッダーが含まれている場合、クライアントは応答エンティティを次の完全な表現として解釈することを許可されます。新しく作成されたエントリ。一致するContent-Locationヘッダーがない場合、クライアントは、返されたエンティティが作成されたリソースの完全な表現であると想定してはなりません（MUSTNOT）。

于 2009-02-02T09:20:57.047 に答える
1

RFC2557 を参照してください: http://www.faqs.org/rfcs/rfc2557.htmlに興味がある場合は、より詳しい説明をご覧ください。私は現在、クラスのためにこれについて書いています。少し古いですが、まだ関連性があります。

于 2011-02-27T00:41:42.830 に答える