[要約] RFC 4437は、WebDAVのリダイレクト参照リソースに関する仕様です。このRFCの目的は、WebDAVクライアントがリダイレクトされたリソースを正しく処理できるようにすることです。
Network Working Group J. Whitehead
Request for Comments: 4437 U.C. Santa Cruz
Category: Experimental G. Clemm
IBM
J. Reschke, Ed.
greenbytes
March 2006
Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
Web分散オーサリングとバージョン（WebDAV）リダイレクトリファレンス
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.
この仕様は、デフォルトの応答がHTTP/1.1 3XX（リダイレクト）ステータスコードであるデフォルトの応答がHTTPリダイレクト参照リソースを作成できるようにするために、Web分散オーサリングおよびバージョン（WebDAV）への拡張機能を定義します。リダイレクトリファレンスにより、リダイレクトリソースにマッピングされたURIを介して間接的にリソースのターゲットにアクセスできます。この仕様は、リソースの木の再マッピングや正規表現ベースのリダイレクトに対処しません。リダイレクト参照リソースに関連する整合性保証はありません。他のメカニズムを使用して、この仕様と同じ機能を達成することもできます。この仕様により、オペレーターはこのメカニズムを実験し、問題に対する最良のアプローチについての経験を開発することができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Notational Conventions ..........................................4
3. Terminology .....................................................4
4. Overview of Redirect Reference Resources ........................5
5. Operations on Redirect Reference Resources ......................6
6. MKREDIRECTREF Method ............................................7
6.1. Example: Creating a Redirect Reference Resource
with MKREDIRECTREF .........................................8
7. UPDATEREDIRECTREF Method ........................................9
7.1. Example: Updating a Redirect Reference Resource with
UPDATEREDIRECTREF .........................................10
8. Operations on Collections That Contain Redirect
Reference Resources ............................................11
8.1. Example: PROPFIND on a Collection with Redirect
Reference .................................................11
8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a
Collection with Redirect Reference Resources ..............13
9. Operations on Targets of Redirect Reference Resources ..........15
10. Relative References in DAV:reftarget ..........................15
10.1. Example: Resolving a Relative Reference in a
Multi-Status Response.....................................16
11. Redirect References to Collections ............................17
12. Headers .......................................................18
12.1. Redirect-Ref Response Header .............................18
12.2. Apply-To-Redirect-Ref Request Header .....................19
13. Redirect Reference Resource Properties ........................19
13.1. DAV:redirect-lifetime (protected) ........................19
13.2. DAV:reftarget (protected) ................................19
14. XML Elements ..................................................19
14.1. redirectref XML Element ..................................19
15. Extensions to the DAV:response XML Element for Multi-Status
Responses .....................................................20
16. Capability Discovery ..........................................20
16.1. Example: Discovery of Support for Redirect
Reference Resources ......................................20
17. Security Considerations .......................................21
17.1. Privacy Concerns .........................................21
17.2. Redirect Loops ...........................................21
17.3. Redirect Reference Resources and Denial of Service .......21
17.4. Revealing Private Locations ..............................22
18. Internationalization Considerations ...........................22
19. IANA Considerations ...........................................22
19.1. HTTP headers .............................................22
19.1.1. Redirect-Ref ......................................22
19.1.2. Apply-To-Redirect-Ref .............................23
20. Contributors ..................................................23
21. Acknowledgements ..............................................23
22. Normative References ..........................................23
This specification extends the Web Distributed Authoring Protocol (WebDAV) to enable clients to create new access paths to existing resources. This capability is useful for several reasons.
この仕様は、クライアントが既存のリソースへの新しいアクセスパスを作成できるようにするために、Web分散オーサリングプロトコル（WebDAV）を拡張します。この機能は、いくつかの理由で役立ちます。
WebDAV makes it possible to organize HTTP resources into hierarchies, placing them into groupings, known as collections, that are more easily browsed and manipulated than a single flat collection. However, hierarchies require categorization decisions that locate resources at a single location in the hierarchy, a drawback when a resource has multiple valid categories. For example, in a hierarchy of vehicle descriptions containing collections for cars and boats, a description of a combination car/boat vehicle could belong in either collection. Ideally, the description should be accessible from both. Allowing clients to create new URIs that access the existing resource lets them put that resource into multiple collections.
WebDavは、HTTPリソースを階層に整理し、コレクションとして知られるグループに配置することを可能にします。コレクションは、単一のフラットコレクションよりも簡単に閲覧および操作されます。ただし、階層には、階層内の単一の場所にリソースを配置する分類決定が必要です。これは、リソースに複数の有効なカテゴリがある場合の欠点です。たとえば、車やボートのコレクションを含む車両の説明の階層では、コンビネーション車/ボートの車両の説明がどちらのコレクションにも属します。理想的には、説明には両方からアクセスできる必要があります。クライアントが既存のリソースにアクセスする新しいURIを作成できるようにすることで、そのリソースを複数のコレクションに入れることができます。
Hierarchies also make resource sharing more difficult, since resources that have utility across many collections are still forced into a single collection. For example, the mathematics department at one university might create a collection of information on fractals that contains bindings to some local resources, but also provides access to some resources at other universities. For many reasons, it may be undesirable to make physical copies of the shared resources: to conserve disk space, to respect copyright constraints, or to make any changes in the shared resources visible automatically. Being able to create new access paths to existing resources in other collections or even on other unrelated systems is useful for this sort of case.
また、多くのコレクションにわたってユーティリティを持つリソースがまだ単一のコレクションに強制されているため、階層はリソース共有をより困難にします。たとえば、ある大学の数学部門は、地元のリソースへのバインディングを含むが、他の大学のいくつかのリソースへのアクセスを提供するフラクタルに関する情報のコレクションを作成する場合があります。多くの理由で、共有リソースの物理的なコピーを作成することは望ましくない場合があります。ディスクスペースを節約したり、著作権の制約を尊重したり、共有リソースの変更を自動的に表示したりすることです。他のコレクションや他の無関係なシステムで既存のリソースへの新しいアクセスパスを作成できることは、この種のケースに役立ちます。
The redirect reference resources defined here provide a mechanism for creating alternative access paths to existing resources. A redirect reference resource is a resource in one collection whose purpose is to redirect requests to another resource (its target), possibly in a different collection. In this way, it allows clients to submit requests to the target resource from another collection. It redirects most requests to the target resource using an HTTP status code from the 3xx range (Redirection), thereby providing a form of mediated access to the target resource.
ここで定義されているリダイレクト参照リソースは、既存のリソースへの代替アクセスパスを作成するためのメカニズムを提供します。リダイレクトリファレンスリソースは、おそらく別のコレクションで、別のリソース（そのターゲット）にリクエストをリダイレクトすることを目的とする1つのコレクションのリソースです。このようにして、クライアントは別のコレクションのターゲットリソースにリクエストを送信できます。3XX範囲のHTTPステータスコード（リダイレクト）を使用して、ほとんどの要求をターゲットリソースにリダイレクトし、ターゲットリソースへの媒介アクセスの形式を提供します。
A redirect reference is a resource with properties but with no body of its own. Properties of a redirect reference resource can contain information such as who created the reference, when, and why. Since redirect reference resources are implemented using HTTP 3xx responses, it generally takes two round trips to submit a request to the intended resource. Redirect references work equally well for local resources and for resources that reside on a different system from the reference.
リダイレクトリファレンスは、プロパティを備えたリソースですが、独自の本文はありません。リダイレクト参照リソースのプロパティには、参照を作成した人、いつ、その理由などの情報を含めることができます。リダイレクト参照リソースはHTTP 3XX応答を使用して実装されるため、通常、意図したリソースにリクエストを送信するには2回のラウンド旅行が必要です。リダイレクト参照は、地元のリソースと、参照とは異なるシステムに存在するリソースに対しても同様に機能します。
The remainder of this document is structured as follows: Section 3 defines terms that will be used throughout the specification. Section 4 provides an overview of redirect reference resources. Section 5 defines the semantics of existing methods when applied to redirect reference resources. Section 6 discusses how to create a redirect reference resource, and Section 7 discusses updating redirect references. Section 8 discusses their semantics when applied to collections that contain redirect reference resources. Sections 9 through 11 discuss several other issues raised by the existence of redirect reference resources. Sections 12 through 15 define the new headers, properties, and XML elements required to support redirect reference resources. Section 16 discusses capability discovery. Sections 17 through 19 present the security, internationalization, and IANA concerns raised by this specification. The remaining sections provide a variety of supporting information.
このドキュメントの残りの部分は、次のように構成されています。セクション3では、仕様全体で使用される用語を定義します。セクション4では、リダイレクト参照リソースの概要を説明します。セクション5では、参照リソースをリダイレクトするために適用された場合の既存のメソッドのセマンティクスを定義します。セクション6では、リダイレクト参照リソースの作成方法について説明し、セクション7ではリダイレクト参照の更新について説明します。セクション8では、リダイレクト参照リソースを含むコレクションに適用された場合、セマンティクスについて説明します。セクション9〜11は、リダイレクト参照リソースの存在によって提起された他のいくつかの問題について説明します。セクション12〜15は、リダイレクト参照リソースをサポートするために必要な新しいヘッダー、プロパティ、およびXML要素を定義します。セクション16では、能力の発見について説明します。セクション17〜19は、この仕様によって提起されたセキュリティ、国際化、およびIANAの懸念を示しています。残りのセクションは、さまざまなサポート情報を提供します。
Since this document describes a set of extensions to the WebDAV Distributed Authoring Protocol [RFC2518], itself an extension to the HTTP/1.1 protocol, the augmented BNF used here to describe protocol elements is exactly the same as described in Section 2.1 of [RFC2616]. Since this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well.
このドキュメントでは、WebDAV分散オーサリングプロトコル[RFC2518]の拡張セットがHTTP/1.1プロトコルの拡張であるため、プロトコル要素を説明するためにここで使用される増強されたBNFは、[RFC2616]のセクション2.1で説明されているとまったく同じです。。この拡張されたBNFは、[RFC2616]のセクション2.2で提供される基本的な生産ルールを使用しているため、これらのルールもこのドキュメントにも適用されます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"[RFC2119]に記載されているように解釈されます。
The terminology used here follows and extends that in the WebDAV Distributed Authoring Protocol specification [RFC2518]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are provided in [RFC3986].
ここで使用される用語は、WebDAV分散オーサリングプロトコル仕様[RFC2518]に続き、拡張されます。[RFC3986]には、用語リソース、ユニフォームリソース識別子（URI）、および均一なリソースロケーター（URL）の定義が提供されています。
Redirect Reference Resource
参照リソースをリダイレクトします
A resource created to redirect all requests made to it, using an HTTP status code from the 3xx range, to a defined target resource.
3xx範囲からHTTPステータスコードを定義されたターゲットリソースに使用して、作成されたすべての要求をリダイレクトするために作成されたリソース。
Non-Reference Resource
非参照リソース
A resource that is not a reference to another resource.
別のリソースへの参照ではないリソース。
Target Resource
ターゲットリソース
The resource to which requests are redirected by a redirect reference resource. A target resource can be anything that can be identified by an absolute URI (see [RFC3986], "absolute-URI").
リクエストがリダイレクトリファレンスリソースによってリダイレクトされるリソース。ターゲットリソースは、絶対URIによって識別できるものすべてにすることができます（[RFC3986]、「Absolute-URI」を参照）。
This document uses the terms "precondition", "postcondition", and "protected property" as defined in [RFC3253]. Servers MUST report pre-/postcondition failures as described in Section 1.6 of this document.
このドキュメントでは、[RFC3253]で定義されているように、「前提条件」、「条件」、「保護されたプロパティ」という用語を使用します。サーバーは、このドキュメントのセクション1.6で説明されているように、事前/条件後の障害を報告する必要があります。
For all operations submitted to a redirect reference resource, the default response is a 302 (Found), accompanied by the Redirect-Ref header (defined in Section 12.1, below) and the Location header ([RFC2616], Section 14.30) set to the URI of the target resource. With this information, the client can resubmit the request to the URI of the target resource.
リダイレクトリファレンスリソースに送信されたすべての操作について、デフォルトの応答は302（見つかります）で、リダイレクトREFヘッダー（以下のセクション12.1で定義）とロケーションヘッダー（[RFC2616]、セクション14.30）を伴います。ターゲットリソースのURI。この情報を使用すると、クライアントはターゲットリソースのURIにリクエストを再提出できます。
A redirect reference resource never automatically forwards requests to its target resource. Redirect resources bring the same benefits as links in HTML documents. They can be created and maintained without the involvement or even knowledge of their target resource. This reduces the cost of linking between resources.
リダイレクトリファレンスリソースは、ターゲットリソースにリクエストを自動的に転送することはありません。リダイレクトリソースは、HTMLドキュメントのリンクと同じ利点をもたらします。それらは、ターゲットリソースの関与や知識さえなく作成および維持することができます。これにより、リソース間のリンクコストが削減されます。
If the client is aware that it is operating on a redirect reference resource, it can resolve the reference by retrieving the reference resource's DAV:reftarget property (defined in Section 13.2, below), whose value contains the URI of the target resource. It can then submit requests to the target resource.
クライアントがリダイレクトリファレンスリソースで動作していることを認識している場合、ターゲットリソースのURIが含まれるリファレンスリソースのDAV：RefTargetプロパティ（以下のセクション13.2で定義）を取得することにより、参照を解決できます。その後、ターゲットリソースにリクエストを送信できます。
A redirect reference resource is a new type of resource. To distinguish redirect reference resources from non-reference resources, a new value of the DAV:resourcetype property (defined in [RFC2518]), DAV:redirectref, is defined in Section 14.1, below.
リダイレクトリファレンスリソースは、新しいタイプのリソースです。リダイレクト参照リソースを非参照リソースと区別するために、DAV：ResourceTypeプロパティ（[RFC2518]で定義）の新しい値、DAV：Redirectrefは、以下のセクション14.1で定義されています。
Since a redirect reference resource is a resource, methods can be applied to the reference resource as well as to its target resource.
リダイレクト参照リソースはリソースであるため、メソッドは参照リソースとそのターゲットリソースに適用できます。
The Apply-To-Redirect-Ref request header (defined in Section 12.2, below) is provided so that referencing-aware clients can control whether an operation is applied to the redirect reference resource or standard HTTP/WebDAV behaviour (redirection with a 3xx status code) should occur. The Apply-To-Redirect-Ref header can be used with most requests to redirect reference resources. This header is particularly useful with PROPFIND, to retrieve the reference resource's own properties.
参照認識クライアントがリダイレクト参照リソースに適用されるか、標準のhttp/webdav動作（3xxステータスのリダイレクトに適用されるかを制御できるように、Redirect-to-Refリクエストヘッダー（以下のセクション12.2で定義）が提供されます。コード）が発生するはずです。Redirect-to-Refヘッダーは、ほとんどのリクエストで参照リソースをリダイレクトするために使用できます。このヘッダーは、参照リソース自身のプロパティを取得するために、Propfindで特に役立ちます。
Implementation Note: Operations on the target of a redirect reference usually do not affect the redirect reference itself. However, clients should not rely on this behaviour (for instance, some servers may update redirect references as a result of namespace operations on the reference's target).
実装注：リダイレクトリファレンスのターゲットでの操作は、通常、リダイレクトリファレンス自体に影響しません。ただし、クライアントはこの動作に依存するべきではありません（たとえば、一部のサーバーは、リファレンスのターゲットの名前空間操作の結果としてリダイレクト参照を更新する場合があります）。
Although non-referencing-aware clients cannot create reference resources, they should be able to submit requests through the reference resources created by reference-aware WebDAV clients. They should be able to follow any references to their targets. To make this possible, a server that receives any request made via a redirect reference resource MUST return a 3xx range (Redirection) status code, unless the request includes an Apply-To-Redirect-Ref header specifying "T". The client and server MUST follow [RFC2616], Section 10.3, but with these additional rules:
非参照認識クライアントは参照リソースを作成することはできませんが、参照認識WebDavクライアントが作成した参照リソースを通じてリクエストを送信できるはずです。彼らは、ターゲットへの参照に従うことができるはずです。これを可能にするために、リダイレクト参照リソースを介して行われたリクエストを受信するサーバーは、「t」を指定するRedirect-to-Refヘッダーが含まれていない限り、3xx範囲（リダイレクト）ステータスコードを返す必要があります。クライアントとサーバーは[RFC2616]、セクション10.3に従う必要がありますが、これらの追加ルールを使用する必要があります。
o The Location response header MUST contain a URI (see [RFC3986], Section 3) that identifies the target of the reference resource.
o ロケーション応答ヘッダーには、参照リソースのターゲットを識別するURI（[RFC3986]、セクション3を参照）を含める必要があります。
o The response MUST include the Redirect-Ref header. This header allows reference-aware WebDAV clients to recognize the resource as a reference resource and to understand the reason for the redirection.
o 応答には、リダイレクトREFヘッダーを含める必要があります。このヘッダーにより、参照認識WebDavクライアントは、リソースを参照リソースとして認識し、リダイレクトの理由を理解することができます。
A reference-aware WebDAV client can, like a non-referencing client, resubmit the request to the URI in the Location header in order to operate on the target resource. Alternatively, it can resubmit the request to the URI of the redirect reference resource with the "Apply-To-Redirect-Ref: T" header in order to operate on the reference resource itself. In this case, the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.
参照認識のWebDavクライアントは、非参照クライアントのように、ターゲットリソースを操作するために、ロケーションヘッダーのURIにリクエストを再送信できます。あるいは、参照リソース自体を操作するために、リダイレクト参照リソースのURIへのリクエストを再提出することができます。この場合、リクエストは参照リソース自体に適用する必要があり、3XX応答を返してはなりません。
As redirect references do not have bodies, GET and PUT requests with "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
リダイレクトリファレンスにはボディがないため、「redirect-to-redirect-ref：t」を使用してリクエストを取得して配置します。ステータス403（禁止）で失敗する必要があります。
The MKREDIRECTREF method requests the creation of a redirect reference resource.
MKREDIRECTREFメソッドは、リダイレクト参照リソースの作成を要求します。
If a MKREDIRECTREF request fails, the server state preceding the request MUST be restored.
mkredirectref要求が失敗した場合、リクエストの前のサーバー状態を復元する必要があります。
Responses from a MKREDIRECTREF request MUST NOT be cached, as MKREDIRECTREF has non-idempotent and non-safe semantics (see [RFC2616], Section 9.1).
mkredirectrefには非高度および非安全性のセマンティクスがあるため、mkredirectrefリクエストからの応答はキャッシュしてはなりません（[RFC2616]、セクション9.1を参照）。
Marshalling
マーシャリング
The request body MUST be a DAV:mkredirectref XML element.
リクエスト本体は、dav：mkredirectref xml要素でなければなりません。
<!ELEMENT mkredirectref (reftarget, redirect-lifetime?)>
<!ELEMENT reftarget (href)>
<!ELEMENT redirect-lifetime (permanent | temporary)>
<!ELEMENT permanent EMPTY>
<!ELEMENT temporary EMPTY>
The DAV:href element is defined in [RFC2518] (Section 12.3) and MUST contain either a URI or a relative-ref (see [RFC3986], Sections 3 and 4.2).
DAV：HREF要素は[RFC2518]（セクション12.3）で定義されており、URIまたは相対REF（[RFC3986]、セクション3および4.2を参照）を含む必要があります。
If no DAV:redirect-lifetime element is specified, the server MUST behave as if a value of DAV:temporary was specified.
dav：redirect-lifetime要素が指定されていない場合、サーバーはdav：一時の値が指定されたかのように動作する必要があります。
If the request succeeds, the server MUST return 201 (Created) status.
リクエストが成功した場合、サーバーは201（作成）ステータスを返す必要があります。
If a response body for a successful request is included, it MUST be a DAV:mkredirectref-response XML element. Note that this document does not define any elements for the MKREDIRECTREF response body, but the DAV:mkredirectref-response element is defined to ensure interoperability between future extensions that do define elements for the response body.
リクエストを成功させるための応答本体が含まれている場合、それはdav：mkredirectref-response xml要素でなければなりません。このドキュメントは、MKREDIRECTREF応答本体の要素を定義していませんが、DAV：MKREDIRECTREF-RESPONSE要素は、応答ボディの要素を定義する将来の拡張間の相互運用性を確保するために定義されていることに注意してください。
<!ELEMENT mkredirectref-response ANY>
Preconditions
前提条件
(DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI.
（DAV：リソースマストビーナル）：リクエスト-URIにリソースが存在してはなりません。
(DAV:parent-resource-must-be-non-null): The Request-URI minus the last past segment MUST identify a collection.
（DAV：Parent-Resource-Must-be-non-null）：リクエスト-URIから最後の過去のセグメントを差し引いてコレクションを特定する必要があります。
(DAV:name-allowed): The last segment of the Request-URI is available for use as a resource name.
（dav：name-allowed）：リクエスト-uriの最後のセグメントは、リソース名として使用できます。
(DAV:locked-update-allowed): If the collection identified by the Request-URI minus the last path segment is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV：ロックアップデートが許可されています）：リクエスト-URIから識別されたコレクションが最後のパスセグメントが書き込みロックされている場合、適切なトークンをIFリクエストヘッダーで指定する必要があります。
(DAV:redirect-lifetime-supported): If the request body contains a DAV:redirect-lifetime element, the server MUST support the specified lifetime. Support for DAV:temporary is REQUIRED, while support for DAV:permanent is OPTIONAL.
（DAV：Redirect-Lifetime-Supported）：要求本体にDAV：Redirect-Lifetime要素が含まれている場合、サーバーは指定された寿命をサポートする必要があります。DAVのサポート：一時的なものが必要ですが、DAV：永久のサポートはオプションです。
(DAV:legal-reftarget): The specified is a legal URI or relative-ref.
（DAV：Legal-Reftarget）：指定されたものは、法的URIまたは相対REFです。
Postconditions
ポストコンディション
(DAV:new-redirectref): a new redirect reference resource is created whose DAV:reftarget property has the value specified in the request body.
（DAV：New-Redirectref）：DAV：RefTargetプロパティには、リクエスト本体で指定された値がある新しいリダイレクトリファレンスリソースが作成されます。
>> Request:
>>リクエスト：
MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkredirectref xmlns:D="DAV:">
<D:reftarget>
<D:href>/i-d/draft-webdav-protocol-08.txt</D:href>
</D:reftarget>
</D:mkredirectref>
>> Response:
>>応答：
HTTP/1.1 201 Created This request resulted in the creation of a new redirect reference resource at http://www.example.com/~whitehead/dav/spec08.ref, which points to the resource identified by the DAV:reftarget property. In this example, the target resource is identified by the URI http://www.example.com/i-d/draft-webdav-protocol-08.txt. The redirect reference resource's DAV:resourcetype property is set to DAV:redirectref, and its DAV:redirect-lifetime property has the value DAV:temporary.
HTTP/1.1 201この要求は、この要求を作成し、http://www.example.com/~whitehead/dav/spec08.refに新しいリダイレクトリファレンスリソースが作成されました。この例では、ターゲットリソースはURI http://www.example.com/i-d/draft-webdav-protocol-08.txtによって識別されます。Redirect Reference ResourceのDAV：ResourceTypeプロパティは、DAV：Redirectref、およびそのDAV：Redirect-LifetimeプロパティにValue DAV：一時的なものに設定されています。
The UPDATEREDIRECTREF method requests the update of a redirect reference resource.
updateredirectrefメソッドは、リダイレクト参照リソースの更新を要求します。
If a UPDATEREDIRECTREF request fails, the server state preceding the request MUST be restored.
updateredirectref要求が失敗した場合、リクエストの前のサーバー状態を復元する必要があります。
Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], Section 9.1).
updateredirectrefには非セーフセマンティクスがあるため、updateredirectrefリクエストからの応答をキャッシュしてはなりません（[RFC2616]、セクション9.1を参照）。
Marshalling
マーシャリング
The request body MUST be a DAV:updateredirectref XML element.
リクエスト本体は、DAV：updateredirectref XML要素でなければなりません。
<!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)>
See Section 6 for a definition of DAV:reftarget and DAV:redirect-lifetime.
DAVの定義については、セクション6を参照してください：RefTargetおよびDAV：Redirect-Lifetime。
If no DAV:reftarget element is specified, the server MUST NOT change the target of the redirect reference.
DAVがない場合：RefTarget要素が指定されている場合、サーバーはリダイレクトリファレンスのターゲットを変更してはなりません。
If no DAV:redirect-lifetime element is specified, the server MUST NOT change the lifetime of the redirect reference.
dav：redirect-lifetime要素が指定されていない場合、サーバーはリダイレクトリファレンスの寿命を変更してはなりません。
If a response body for a successful request is included, it MUST be a DAV:updateredirectref-response XML element. Note that this document does not define any elements for the UPDATEREDIRECTREF response body, but the DAV:updateredirectref-response element is defined to ensure interoperability between future extensions that do define elements for the response body.
リクエストを成功させるための応答本体が含まれている場合、それはDAV：updateredirectref-response xml要素でなければなりません。このドキュメントは、updateredirectref応答本体の要素を定義していませんが、dav：updateredirectref-response要素は、応答ボディの要素を定義する将来の拡張間の相互運用性を確保するために定義されています。
<!ELEMENT updateredirectref-response ANY>
Preconditions
前提条件
(DAV:locked-update-allowed): if the resource is write-locked, then the appropriate token MUST be specified in an If request header.
（DAV：ロックされたアップデートが許可されています）：リソースが書き込みロックされている場合、適切なトークンをIFリクエストヘッダーで指定する必要があります。
(DAV:must-be-redirectref): the resource identified by the Request-URI must be a redirect reference resource as defined by this specification.
（DAV：必須redirectref）：リクエスト-URIによって識別されるリソースは、この仕様で定義されているリダイレクト参照リソースでなければなりません。
(DAV:redirect-lifetime-supported): see Section 6.
（DAV：Redirect-Lifetime-Supported）：セクション6を参照してください。
(DAV:redirect-lifetime-update-supported): servers MAY support changing the DAV:redirect-lifetime property; if they don't, this condition code can be used to signal failure.
（DAV：Redirect-Lifetime-Update-Supported）：サーバーは、DAV：Redirect-Lifetimeプロパティの変更をサポートする場合があります。そうでない場合、この条件コードを使用して障害を信号することができます。
(DAV:legal-reftarget): see Section 6.
（DAV：Legal-Reftarget）：セクション6を参照してください。
Postconditions
ポストコンディション
(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-lifetime properties of the redirect reference have been updated accordingly.
（DAV：Redirectref-Updated）：The DAV：RefTarget and DAV：リダイレクトリファレンスのリダイレクトライフタイムプロパティは、それに応じて更新されています。
>> Request:
>>リクエスト：
UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1
Host: www.example.com
Apply-To-Redirect-Ref: T
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:updateredirectref xmlns:D="DAV:">
<D:reftarget>
<D:href>/i-d/draft-webdav-protocol-08b.txt</D:href>
</D:reftarget>
</D:updateredirectref>
>> Response:
>>応答：
HTTP/1.1 200 OK
HTTP/1.1 200 OK
This request has updated the redirect reference's DAV:reftarget property to "/i-d/draft-webdav-protocol-08b.txt" and has not changed the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- Ref" request header must be used; otherwise, the request would result in a redirect (3xx) response status.
このリクエストは、Redirect ReferenceのDAV：RefTargetプロパティを「/I-d/Draft-webdav-protocol-08b.txt」に更新し、DAV：Redirect-Lifetime値を変更していません。「redirect-to-redirect-ref」リクエストヘッダーを使用する必要があることに注意してください。それ以外の場合、リクエストはリダイレクト（3xx）応答ステータスになります。
According to [RFC2518], Section 9.2, methods that have defined interactions with the "Depth" request header should apply all other request headers to each resource in scope. However, applying this principle to the "Apply-To-Redirect-Ref" header uniformly would make it impractical to implement this specification on top of existing servers and also would result in unexpected server behaviour for clients that do not take the existence of redirect references into account. On the other hand, the definition of the "Depth" header allows alternate behaviours to be explicitly defined.
[RFC2518]、セクション9.2によれば、「深度」要求ヘッダーとの相互作用を定義した方法は、他のすべての要求ヘッダーを各リソースに範囲内に適用する必要があります。ただし、この原則を「リダイレクトに適用する」ヘッダーに均一に適用すると、既存のサーバーの上にこの仕様を実装し、リダイレクト参照の存在を取らないクライアントに予期しないサーバー動作をもたらすことが実用的になります。考慮されます。一方、「深さ」ヘッダーの定義により、代替の動作を明示的に定義できます。
For this reason, this specification defines the interaction between "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case basis and also provides a default for methods not mentioned here that do not specify the behaviour themselves.
このため、この仕様では、「深さ」と「適用 - redirect-ref」要求ヘッダーの間の相互作用をケースバイケースで定義し、動作自体を指定しないここで言及されていないメソッドのデフォルトを提供します。
+-------------+-----------------+------------------+-----------+
| method name | defined in | supported depths | behaviour |
+-------------+-----------------+------------------+-----------+
| COPY | [RFC2518], 8.9 | 0, infinity | "T" |
| DELETE | [RFC2518], 8.7 | infinity | "T" |
| LOCK | [RFC2518], 8.11 | 0, infinity | "T" |
| MOVE | [RFC2518], 8.10 | 0, infinity | "T" |
| PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit |
| REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit |
| default | | | "T" |
+-------------+-----------------+------------------+-----------+
When the behaviour is defined to be "inherit", the method should follow RFC2518's default behaviour for "Depth" operations, which means applying the value given for "Apply-To-Redirect-Ref" to each resource in scope. On the other hand, when it is defined to be "T", the method should behave as if a "Apply-To-Redirect-Ref: T" header was specified for each operation on child resources. The latter ensures that "Depth: infinity" operations will not fail unexpectedly just because there was a redirect reference resource in scope.
動作が「継承」と定義されている場合、メソッドは「深さ」操作のRFC2518のデフォルト動作に従う必要があります。一方、「t」と定義される場合、メソッドは、子どものリソースの各操作に「適用対応 - ref：t」ヘッダーが指定されたかのように振る舞う必要があります。後者は、範囲にリダイレクト参照リソースがあったという理由だけで、「深さ：無限」操作が予期せずに失敗しないことを保証します。
Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here:
深さのプロパンドリクエスト：Infinityが次のコレクションに提出され、メンバーがここに示されていると仮定します。
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
/ myCollection/（非参照リソース）Diary.html（リダイレクトリファレンスリソース）nunavut
>> Request:
>>リクエスト：
PROPFIND /MyCollection/ HTTP/1.1
Host: example.com
Depth: infinity
Apply-To-Redirect-Ref: F
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV: ">
<D:prop xmlns:J="http://example.com/jsprops/">
<D:resourcetype/>
<J:keywords/>
</D:prop>
</D:propfind>
>> Response:
>>応答：
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" xmlns:J="http://example.com/jsprops/">
<D:response>
<D:href>/MyCollection/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
<J:keywords>diary, interests, hobbies</J:keywords>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/diary.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:keywords>diary, travel, family, history</J:keywords>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/nunavut</D:href>
<D:status>HTTP/1.1 302 Found</D:status>
<D:location>
<D:href>http://example.ca/art/inuit/</D:href>
</D:location>
</D:response>
</D:multistatus>
In this example, the Depth header is set to infinity, and the Apply-To-Redirect-Ref header is set to "F". The collection contains one URI that identifies a redirect reference resource. The response element for the redirect reference resource has a status of 302 (Found) and includes a DAV:location extension element to allow clients to retrieve the properties of its target resource. (The response element for the redirect reference resource does not include the requested properties. The client can submit another PROPFIND request to the URI in the DAV:location pseudo-property to retrieve those properties.)
この例では、深度ヘッダーは無限に設定され、適用redirect-to-refヘッダーは「F」に設定されます。コレクションには、リダイレクトリファレンスリソースを識別する1つのURIが含まれています。Redirect Reference Resourceの応答要素のステータスは302（見つかります）を持ち、DAV：ロケーション拡張要素が含まれ、クライアントがターゲットリソースのプロパティを取得できるようにします。（リダイレクトリファレンスリソースの応答要素には、要求されたプロパティが含まれていません。クライアントは、DAVのURIに別のPropfindリクエストを送信できます。
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: infinity is submitted to the following collection, with the members shown here:
「redirect-to-redirect-ref：t」と深さ：Infinityが次のコレクションに提出されたPropfind requestが次のようになり、メンバーがここに表示されます。
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
/ myCollection/（非参照リソース）Diary.html（リダイレクトリファレンスリソース）nunavut
>> Request:
>>リクエスト：
PROPFIND /MyCollection/ HTTP/1.1
Host: example.com
Depth: infinity
Apply-To-Redirect-Ref: T
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:resourcetype/>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
</D:propfind>
>> Response:
>>応答：
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/MyCollection/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/diary.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/nunavut</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget>
<D:href>http://example.ca/art/inuit/</D:href>
</D:reftarget>
<D:redirect-lifetime><D:temporary/></D:redirect-lifetime>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Since the "Apply-To-Redirect-Ref: T" header is present, the response shows the properties of the redirect reference resource in the collection rather than reporting a 302 status.
「redirect-to-redirect-ref：t」ヘッダーが存在するため、応答は302ステータスを報告するのではなく、コレクション内のリダイレクト参照リソースのプロパティを示しています。
Operations on targets of redirect reference resources have no effect on the reference resource.
リダイレクト参照リソースのターゲットの操作は、参照リソースに影響を与えません。
The URI in the href in a DAV:reftarget property MAY be a relative reference. In this case, the base URI to be used for resolving it to absolute form is the URI used in the HTTP message to identify the redirect reference resource to which the DAV:reftarget property belongs.
dav：reftargetプロパティのHREFのURIは、相対的な参照である場合があります。この場合、絶対フォームに解決するために使用されるベースURIは、HTTPメッセージで使用されるURIであり、DAV：RefTargetプロパティが属するリダイレクト参照リソースを識別します。
When DAV:reftarget appears in the context of a Multi-Status response, it is in a DAV:response element that contains a single DAV:href element. The value of this DAV:href element serves as the base URI for resolving a relative reference in DAV:reftarget. The value of DAV:href may itself be relative, in which case it must be resolved first in order to serve as the base URI for the relative reference in DAV:reftarget. If the DAV:href element is relative, its base URI is constructed from the scheme component "http", the value of the Host header in the request, and the Request-URI.
DAV：RefTargetがマルチステータス応答のコンテキストで表示される場合、それは単一のDAV：HREF要素を含むDAV：応答要素にあります。このDAVの値：HREF要素は、DAV：RefTargetで相対的な参照を解決するためのベースURIとして機能します。DAVの価値：HREF自体が相対的である可能性があります。その場合、DAV：RefTargetの相対的な参照のベースURIとして機能するために、最初に解決する必要があります。DAV：HREF要素が相対的である場合、そのベースURIはスキームコンポーネント「HTTP」、リクエストのホストヘッダーの値、およびリクエスト-URIから構築されます。
>> Request:
>>リクエスト：
PROPFIND /geog/ HTTP/1.1
Host: example.com
Apply-To-Redirect-Ref: T
Depth: 1
Content-Type: text/xml
Content-Length: nnn
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:resourcetype/>
<D:reftarget/>
</D:prop>
</D:propfind>
>> Response:
>>応答：
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: nnn
<?xml version="1/0" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/geog/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><D:reftarget/></D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/geog/stats.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget>
<D:href>statistics/population/1997.html</D:href>
</D:reftarget>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
In this example, the relative reference "statistics/population/1997.html" is returned as the value of the DAV:reftarget property for the reference resource identified by href /geog/stats.html. The href is itself a relative reference, which resolves to http://example.com/geog/stats.html. This is the base URI for resolving the relative reference in reftarget. The absolute URI of reftarget is http://example.com/geog/statistics/population/1997.html.
この例では、相対的な参照「統計/人口/1997.html」は、href/geog/stats.htmlによって識別された参照リソースのdav：reftargetプロパティの値として返されます。HREF自体は相対的な参照であり、http：//example.com/geog/stats.htmlに解決します。これは、RefTargetの相対参照を解決するためのベースURIです。RefTargetの絶対的なURIはhttp://example.com/geog/statistics/population/1997.htmlです。
In a Request-URI /segment1/segment2/segment3, any of the three segments may identify a redirect reference resource. (See [RFC3986], Section 3.3, for definitions of "path" and "segment".) If any segment in a Request-URI identifies a redirect reference resource, the response SHOULD be a 3xx. The value of the Location header in the response is as follows:
Request-URI/segment1/segment2/segment3では、3つのセグメントのいずれかがリダイレクト参照リソースを識別する場合があります。（[パス]と「セグメント」の定義については、[RFC3986]、セクション3.3を参照してください。）リクエスト-URIのセグメントがリダイレクトリファレンスリソースを識別する場合、応答は3XXでなければなりません。応答の位置ヘッダーの値は次のとおりです。
The leftmost path segment of the Request-URI that identifies a redirect reference resource, together with all path segments and separators to the left of it, is replaced by the value of the redirect reference resource's DAV:reftarget property (resolved to an absolute URI). The remainder of the Request-URI is concatenated to this path.
リダイレクトリファレンスリソースを識別するリクエスト-URIの左端パスセグメントは、その左側にあるすべてのパスセグメントとセパレーターとともに、リダイレクトリソースの値の値に置き換えられます。。リクエスト-URIの残りの部分は、このパスに連結されています。
Note: If the DAV:reftarget property ends with a "/" and the remainder of the Request-URI is non-empty (and therefore must begin with a "/"), the final "/" in the DAV:reftarget property is dropped before the remainder of the Request-URI is appended.
注：dav：reftargetプロパティが「/」で終了し、リクエスト-uriの残りが空ではない（したがって「/」で開始する必要がある）場合、dav：reftargetプロパティの最終「/」Request-URIの残りの部分が追加される前にドロップされました。
Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect reference resource, whose target resource is collection /a/, which contains redirect reference resource y whose target resource is collection /b/, which contains redirect reference resource z.html, whose target resource is /c/d.html.
request-uri /x/y/z.htmlを検討してください。/x /がターゲットリソースがコレクション /a /であるリダイレクト参照リソースであると仮定/d.html。
/x/y/z.html
|
| /x -> /a
|
v
/a/y/z.html
|
| /a/y -> /b
|
v
/b/z.html
|
| /b/z.html -> /c/d.html
|
v
/c/d.html
In this case, the client must follow up three separate 3xx responses before finally reaching the target resource. The server responds to the initial request with a 3xx with Location: /a/y/z.html, and the client resubmits the request to /a/y/z.html. The server responds to this request with a 3xx with Location: /b/z.html, and the client resubmits the request to /b/z.html. The server responds to this request with a 3xx with Location: /c/d.html, and the client resubmits the request to /c/d.html. This final request succeeds.
この場合、クライアントは最終的にターゲットリソースに到達する前に、3つの個別の3XX応答をフォローアップする必要があります。サーバーは、場所の3xxを使用して最初の要求に応答します。サーバーは、このリクエストに、場所：/b/z.htmlを備えた3xxで応答し、クライアントはリクエストを /b /z.htmlに再送信します。サーバーは、このリクエストに3xxが場所の3xxで応答します：/c/d.html、およびクライアントはリクエストを/c/d.htmlに再サビングします。この最終リクエストは成功します。
Note: The behaviour described above may have a very serious impact on the efficiency of mapping Request-URIs to resources in HTTP request processing. Therefore, servers MAY respond with a 404 status code if the cost of checking all leading path segments for redirect references seems prohibitive.
注：上記の動作は、HTTPリクエスト処理のリソースへのマッピングリクエスト-urisの効率に非常に深刻な影響を与える可能性があります。したがって、リダイレクト参照のすべての主要なパスセグメントをチェックするコストが法外にあると思われる場合、サーバーは404ステータスコードで応答する場合があります。
Redirect-Ref = "Redirect-Ref:" (URI | relative-ref)
; URI: see [RFC3986], Section 3
; relative-ref: see [RFC3986], Section 4.2
The Redirect-Ref header is used in all 3xx responses from redirect reference resources. The value is the link target as specified during redirect reference resource creation.
Redirect-REFヘッダーは、リダイレクトリファレンスリソースからのすべての3XX応答で使用されます。値は、リダイレクト参照リソースの作成中に指定されているリンクターゲットです。
Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
The optional Apply-To-Redirect-Ref header can be used on any request to a redirect reference resource. When it is present and set to "T", the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.
オプションのApply-to-Redirect-Refヘッダーは、リダイレクトリファレンスリソースへの任意のリクエストで使用できます。存在して「t」に設定されている場合、リクエストは参照リソース自体に適用する必要があり、3xx応答を返してはなりません。
If the Apply-To-Redirect-Ref header is used on a request to any other sort of resource besides a redirect reference resource, the server MUST ignore it.
リダイレクトリソースリソース以外に、他の種類のリソースへのリクエストで、リダイレクトリソースへの応用ヘッダーが使用されている場合、サーバーはそれを無視する必要があります。
The properties defined below are REQUIRED on redirect reference resources. A PROPFIND/allprop request SHOULD NOT return any of the properties defined in this document.
以下に定義されているプロパティは、リダイレクト参照リソースで必要です。Propfind/allPropリクエストは、このドキュメントで定義されているプロパティのいずれを返さないでください。
This property provides information about the lifetime of a redirect. It can be either DAV:permanent (HTTP status 301) or DAV:temporary (HTTP status 302). Future protocols may define additional values.
このプロパティは、リダイレクトの寿命に関する情報を提供します。DAV：永続的（HTTPステータス301）またはDAV：一時的（HTTPステータス302）のいずれかです。将来のプロトコルは、追加の値を定義する場合があります。
<!ELEMENT redirect-lifetime (permanent | temporary)>
<!ELEMENT permanent EMPTY>
<!ELEMENT temporary EMPTY>
This property provides an efficient way for clients to discover the URI of the target resource. This is a read-only property after its initial creation. Its value can only be set in a MKREDIRECTREF request. The value is a DAV:href element containing the URI of the target resource.
このプロパティは、クライアントがターゲットリソースのURIを発見するための効率的な方法を提供します。これは、最初の作成後の読み取り専用のプロパティです。その値は、mkredirectrefリクエストでのみ設定できます。値は、ターゲットリソースのURIを含むDAV：HREF要素です。
<!ELEMENT reftarget href >
Name: redirectref
名前：Redirectref
Namespace: DAV: Purpose: Used as the value of the DAV:resourcetype property to specify that the resource type is a redirect reference resource.
名前空間：DAV：目的：DAV：ResourceTypeプロパティの値として使用して、リソースタイプがリダイレクト参照リソースであることを指定します。
<!ELEMENT redirectref EMPTY >
As described in Section 8, the DAV:location element may be returned in the DAV:response element of a 207 Multi-Status response, to allow clients to resubmit their requests to the target resource of a redirect reference resource.
セクション8で説明されているように、DAV：ロケーション要素は、207マルチステータス応答のDAV：応答要素で返される場合があります。
Consequently, the definition of the DAV:response XML element changes to the following:
その結果、DAVの定義：応答XML要素は次のものに変更されます。
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?, location?) >
<!ELEMENT location (href) >
Sections 9.1 and 15 of [RFC2518] describe the use of compliance classes with the DAV header in responses to OPTIONS, to indicate which parts of the WebDAV Distributed Authoring protocols the resource supports. This specification defines an OPTIONAL extension to [RFC2518]. It defines a new compliance class, called redirectrefs, for use with the DAV header in responses to OPTIONS requests. If a resource does support redirect references, its response to an OPTIONS request may indicate that it does, by listing the new redirectrefs compliance class in the DAV header and by listing the MKREDIRECTREF method as one it supports.
[RFC2518]のセクション9.1および15は、オプションへの応答でDAVヘッダーを使用したコンプライアンスクラスの使用について、WebDAV分散オーサリングプロトコルのどの部分がリソースをサポートするかを示します。この仕様は、[RFC2518]のオプションの拡張機能を定義します。オプションリクエストへの応答でDAVヘッダーで使用するために、Redirectrefsと呼ばれる新しいコンプライアンスクラスを定義します。リソースがリダイレクト参照をサポートしている場合、オプションリクエストに対するその応答は、DAVヘッダーの新しいRedirectrefsコンプライアンスクラスをリストし、MKREDIRECTREFメソッドをサポートするものとしてリストすることにより、それがそうであることを示している可能性があります。
When responding to an OPTIONS request, any type of resource can include redirectrefs in the value of the DAV header. Doing so indicates that the server permits a redirect reference resource at the Request-URI.
オプションリクエストに応答する場合、あらゆるタイプのリソースには、DAVヘッダーの値にRedirectrefsを含めることができます。そうすることは、サーバーがリクエスト-URIでリダイレクト参照リソースを許可することを示しています。
>> Request:
>>リクエスト：
OPTIONS /somecollection/someresource HTTP/1.1 Host: example.org
options/somecollection/someresource http/1.1ホスト：example.org
>> Response:
>>応答：
HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF DAV: 1, 2, redirectrefs
http/1.1 200 ok許可：オプション、Get、Head、Post、Put、Delete、Trace、Copy、Move Allow：mkcol、propfind、proppatch、lock、lock、lock、mkredirectref dav：1、2、redirectrefs
The DAV header in the response indicates that the resource /somecollection/someresource is level 1 and level 2 compliant, as defined in [RFC2518]. In addition, /somecollection/someresource supports redirect reference resources. The Allow header indicates that MKREDIRECTREF requests can be submitted to /somecollection/someresource.
応答のDAVヘッダーは、[RFC2518]で定義されているように、リソース /SomeCollection /Someresourceがレベル1およびレベル2に準拠していることを示しています。さらに、 /somecollection /someresourceはリダイレクト参照リソースをサポートします。Allowヘッダーは、mkredirectrefリクエストを /somecollection /someresourceに提出できることを示しています。
This section is provided to make applications that implement this protocol aware of the security implications of this protocol.
このセクションは、このプロトコルのセキュリティへの影響をこのプロトコルを実装するアプリケーションを作成するために提供されます。
All of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification. In addition, redirect reference resources introduce several new security concerns and increase the risk of some existing threats. These issues are detailed below.
HTTP/1.1のセキュリティに関するすべての考慮事項とWebDAV分散オーサリングプロトコル仕様も、このプロトコル仕様にも適用されます。さらに、リダイレクト参照リソースはいくつかの新しいセキュリティ上の懸念を導入し、既存の脅威のリスクを高めます。これらの問題については、以下に詳しく説明しています。
By creating redirect reference resources on a trusted server, it is possible for a hostile agent to induce users to send private information to a target on an unrelated system. This risk is mitigated somewhat, since clients are required to notify the user of the redirection for any request other than GET or HEAD. (See [RFC2616], Section 10.3.3, 302 Found.)
信頼できるサーバーでリダイレクト参照リソースを作成することにより、敵対的なエージェントがユーザーに無関係なシステムのターゲットに個人情報を送信するように誘導することができます。クライアントは、GetまたはHead以外のリクエストに対してリダイレクトをユーザーに通知する必要があるため、このリスクは多少軽減されます。（[RFC2616]、セクション10.3.3、302が見つかりました。）
Although redirect loops were already possible in HTTP 1.1, the introduction of the MKREDIRECTREF method creates a new avenue for clients to create loops accidentally or maliciously. If the reference resource and its target are on the same server, the server may be able to detect MKREDIRECTREF requests that would create loops. See also [RFC2616], Section 10.3, "Redirection 3xx."
HTTP 1.1ではリダイレクトループがすでに可能でしたが、MKREDIRECTREFメソッドの導入により、クライアントが偶然または悪意を持ってループを作成するための新しい手段が作成されます。参照リソースとそのターゲットが同じサーバー上にある場合、サーバーはループを作成するMKREDIRECTREFリクエストを検出できる場合があります。[RFC2616]、セクション10.3、「Redirection 3XX」も参照してください。
Denial of service attacks were already possible by posting URLs that were intended for limited use at heavily used Web sites. The introduction of MKREDIRECTREF creates a new avenue for similar denial of service attacks. Clients can now create redirect reference resources at heavily used sites to target locations that were not designed for heavy usage.
サービスの拒否攻撃は、使用されているWebサイトでの使用が限られているURLを投稿することにより、すでに可能でした。Mkredirectrefの導入は、同様のサービス攻撃のための新しい道を作成します。クライアントは、使用されているサイトでリダイレクトリソースを作成して、重い使用法のために設計されていない場所をターゲットにすることができます。
There are several ways that redirect reference resources may reveal information about collection structures. First, the DAV:reftarget property of every redirect reference resource contains the URI of the target resource. Anyone who has access to the reference resource can discover the collection path that leads to the target resource. The owner of the target resource may have wanted to limit knowledge of this collection structure.
参照リソースをリダイレクトする方法は、収集構造に関する情報を明らかにする可能性があります。まず、すべてのリダイレクト参照リソースのRefTargetプロパティには、ターゲットリソースのURIが含まれています。参照リソースにアクセスできる人なら誰でも、ターゲットリソースにつながるコレクションパスを発見できます。ターゲットリソースの所有者は、このコレクション構造の知識を制限したいと考えていたかもしれません。
Sufficiently powerful access control mechanisms can control this risk to some extent. Property-level access control could prevent users from examining the DAV:reftarget property. (The Location header returned in responses to requests on redirect reference resources reveals the same information, however.)
十分に強力なアクセス制御メカニズムは、このリスクをある程度制御できます。プロパティレベルのアクセス制御により、ユーザーがDAV：RefTargetプロパティを調べることができなくなります。（リダイレクト参照リソースのリクエストへの応答で返されたロケーションヘッダーは、同じ情報を明らかにします。）
This risk is no greater than the similar risk posed by HTML links.
このリスクは、HTMLリンクによってもたらされる同様のリスクよりも大きくありません。
All internationalization considerations mentioned in [RFC2518] also apply to this document.
[RFC2518]で言及されているすべての国際化に関する考慮事項もこの文書に適用されます。
All IANA considerations mentioned in [RFC2518] also apply to this document.
[RFC2518]で言及されているIANAの考慮事項はすべて、このドキュメントにも適用されます。
This document specifies the two new HTTP headers listed below.
このドキュメントは、以下にリストされている2つの新しいHTTPヘッダーを指定します。
Header field name: Redirect-Ref
ヘッダーフィールド名：Redirect-Ref
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 12.1)
仕様文書：この仕様（セクション12.1）
Header field name: Apply-To-Redirect-Ref
ヘッダーフィールド名：Apply-to-Redirect-Ref
Applicable protocol: http
該当するプロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document: this specification (Section 12.2)
仕様文書：この仕様（セクション12.2）
Many thanks to Jason Crawford, Jim Davis, Chuck Fay, and Judith Slein, who can take credit for big parts of the original design of this specification.
Jason Crawford、Jim Davis、Chuck Fay、およびJudith Sleinに感謝します。
This document has benefited from thoughtful discussion by Jim Amsden, Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
この文書は、ジム・アムスデン、ピーター・カールソン、スティーブ・カーター、タイソン・チハヤ、ケン・コール、エリス・コーエン、ブルース・クラグン、スペンサー・ドーキンス、マーク・デイ、ラジブ・デュレペット、デビッド・デュランド、リサ・ドッシー、ステファン・アイシング、ロイ・フィールド、ヤロン・ゴーランド、フレッド・ヒット、アレックス・ホップマン、ジェームズ・ハント、マーカス・ジェイガー、クリス・カラー、マノジ・カシチャニュラ、ロヒト・カレ、ダニエル・ラリベルテ、スティーブ・マーティン、ラリー・マシン、ジェフ・マカファー、ジョー・オートン、スレンドラ・コドゥル・レディ、ジュエルゲン・レーテル、ルビー、ブラッドリー・軍曹、ニック・シェルネス、ジョン・ストラック、ジョン・ティグ、ジョン・ターナー、ケビン・ウィッゲンなど。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253] Clemm、G.、Amsden、J.、Ellison、T.、Kaler、C。、およびJ. Whitehead、「WebDavへのバージョン化拡張機能（Web分散オーサリングとバージョン化）」、RFC 3253、2002年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
Authors' Addresses
著者のアドレス
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 US
ジムホワイトヘッドUCサンタクルス、コンピューターサイエンス部1156ハイストリートサンタクルス、カリフォルニア州95064米国
EMail: ejw@cse.ucsc.edu
Geoff Clemm IBM 20 Maguire Road Lexington, MA 02421 US
Geoff Clemm IBM 20 Maguire Road Lexington、MA 02421 US
EMail: geoffrey.clemm@us.ibm.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke（編集者）Greenbytes Gmbh Hafenweg 16 Muenster、NW 48155ドイツ
Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。