RFC4437 日本語訳
4437 Web Distributed Authoring and Versioning (WebDAV) RedirectReference Resources. J. Whitehead, G. Clemm, J. Reschke, Ed.. March 2006. (Format: TXT=49932 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Whitehead
Request for Comments: 4437 U.C. Santa Cruz
Category: Experimental G. Clemm
IBM
J. Reschke, Ed.
greenbytes
March 2006
コメントを求めるワーキンググループJ.ホワイトヘッド要求をネットワークでつないでください: 4437年のU.C.サンタクルスカテゴリ: エド実験的なG.クレムIBM J.Reschke、greenbytes行進2006
Web Distributed Authoring and Versioning (WebDAV)
Redirect Reference Resources
ウェブの分配されたオーサリングとVersioning(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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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の再直接の参照用の情報資源を書くのを許容するためにウェブDistributed AuthoringとVersioning(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
1. 序論…3 2. 記号法のコンベンション…4 3. 用語…4 4. 再直接の参照用の情報資源の概要…5 5. 再直接の参照用の情報資源における操作…6 6. MKREDIRECTREFメソッド…7
Whitehead, et al. Experimental [Page 1] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[1ページ]RFC4437WebDAV
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
6.1. 例: MKREDIRECTREFと共に再直接の参照リソースを作成します…8 7. UPDATEREDIRECTREFメソッド…9 7.1. 例: UPDATEREDIRECTREFと共に再直接の参照リソースをアップデートします…10 8. 再直接の参照用の情報資源を含む収集の操作…11 8.1. 例: 再直接の参照との収集でのPROPFIND…11 8.2. 例: 再直接の参照との収集のときに再直接の審判に適用しているリソースがあるPROPFIND…13 9. 再直接の参照用の情報資源の目標における操作…15 10. DAVの相対参照: reftarget…15 10.1. 例: マルチ状態応答における相対参照を決議します…16 11. 収集の参照を向け直してください…17 12. ヘッダー…18 12.1. 再直接の審判の応答ヘッダ…18 12.2. 審判を向け直すのに申し込んでいる要求ヘッダー…19 13. 参照リソースの特性を向け直してください…19 13.1. DAV: 再直接の生涯(保護されます)…19 13.2. DAV: reftarget(保護されます)…19 14. XML Elements…19 14.1. redirectref XML Element…19 15. DAVへの拡大: マルチ状態応答のための応答XML要素…20 16. 能力発見…20 16.1. 例: 再直接の参照用の情報資源のサポートの発見…20 17. セキュリティ問題…21 17.1. プライバシー関心…21 17.2. 輪を向け直してください…21 17.3. 参照用の情報資源とサービス妨害を向け直してください…21 17.4. 顕な個人的な位置…22 18. 国際化問題…22 19. IANA問題…22 19.1. HTTPヘッダ…22 19.1.1. 再直接の審判…22 19.1.2. 審判を向け直すのに申し込んでください…23 20. 貢献者…23 21. 承認…23 22. 標準の参照…23
Whitehead, et al. Experimental [Page 2] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[2ページ]RFC4437WebDAV
1. Introduction
1. 序論
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.
この仕様は、クライアントが新しいアクセス経路を既存のリソースに作成するのを可能にするために、ウェブDistributed Authoringプロトコル(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.
また、階層構造で、リソース・シェアリングは、より難しくなります、多くの収集の向こう側にユーティリティを持っているリソースがまだただ一つの収集に強制されているので。 例えば、1つの大学の数学部はフラクタルにおけるいくつかのローカル資源に結合を含んでいますが、他の大学でいくつかのリソースへのアクセスをまた提供する情報の収集を作成するかもしれません。 種々の理由で、共用資源の物理的なコピーを作るのは望ましくないかもしれません: 椎間腔を保存するか、著作権規制を尊敬するか、または自動的に共用資源のどんな変更も目に見えるようにするように。 他の収集、または、他の関係ないシステムの上でさえ新しいアクセス経路を既存のリソースに作成できるのはこの種類に関するケースの役に立ちます。
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ステータスコードを使用することで目標リソースにほとんどの要求を向け直します、その結果、目標リソースへの調停されたアクセスのフォームを提供します。
Whitehead, et al. Experimental [Page 3] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[3ページ]RFC4437WebDAV
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.
再直接の参照は特性にもかかわらず、それ自身のボディーがなければリソースです。 再直接の参照リソースの特性はだれが参照、いつ、理由を作成したかなどの情報を含むことができます。 再直接の参照用の情報資源がHTTP3xx応答を使用することで実装されるので、一般に、意図しているリソースに要求を提出するのに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関心を提示します。 残っているセクションはさまざまなサポートするのに情報を提供します。
2. Notational Conventions
2. 記号法のコンベンション
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.
このドキュメントが1セットの拡大について説明するので、WebDAV Distributed Authoringプロトコル[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].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
3. Terminology
3. 用語
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 Distributed Authoringプロトコル仕様[RFC2518]でそれに続いて、広げています。 用語リソース、Uniform Resource Identifier(URI)、およびUniform Resource Locator(URL)の定義を[RFC3986]に提供します。
Whitehead, et al. Experimental [Page 4] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[4ページ]RFC4437WebDAV
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で特定できる何かであるかもしれません(「絶対URI」と見てください[RFC3986])。
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]で定義されるように「前提条件」という用語、"postcondition"、および「保護された特性」を使用します。 サーバはこのセクション1.6における説明されるとしてのpostconditionの故障が記録するプレ/を報告しなければなりません。
4. Overview of Redirect Reference Resources
4. 再直接の参照用の情報資源の概要
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.
再直接の参照リソースに提出されたすべての操作のために、デフォルト応答はRedirect-審判ヘッダー(セクション12.1で定義されて、以下の)によって同伴された302歳(見つけられる)です、そして、Locationヘッダー([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.
クライアントが再直接の参照リソースを作動させているのを意識しているなら、参照リソースのDAVを検索することによって、参照を決議できます: reftargetの特性(セクション13.2で定義されて、以下の)。その値は目標リソースのURIを含みます。 そして、それは目標リソースに要求を提出できます。
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.
再直接の参照リソースがリソースであるので、目標リソースに関してまた、参照リソースにメソッドを適用できます。
Whitehead, et al. Experimental [Page 5] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[5ページ]RFC4437WebDAV
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.
Applyから再直接の審判への要求ヘッダー(セクション12.2で定義されて、以下の)を提供するので、参照をつけて意識しているクライアントが、操作が再直接の参照リソースか標準のHTTP/WebDAVに適用されるかどうかを制御できるのをふるまい(3xxステータスコードがあるリダイレクション)は起こるべきです。 参照用の情報資源を向け直すというほとんどの要求と共にApplyから再直接の審判へのヘッダーを使用できます。 このヘッダーは、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).
実装注意: 通常、再直接の参照の目標における操作は再直接の参照自体に影響しません。 しかしながら、クライアントはこのふるまいに依存するべきではありません(例えば、いくつかのサーバが参照の目標における名前空間操作の結果、再直接の参照をアップデートするかもしれません)。
5. Operations on Redirect Reference Resources
5. 再直接の参照用の情報資源における操作
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クライアントによって作成された参照用の情報資源を通した要求を提出できるべきです。 それらはそれらの目標のどんな参照にも続くことができるべきです。 これを可能にするように、再直接の参照リソースでされたどんな要求も受け取るサーバは3xx範囲(リダイレクション)ステータスコードを返さなければなりません、要求がApplyから再直接の審判への「T」を指定するヘッダーを含んでいない場合。 [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 Location応答ヘッダは参照リソースの目標を特定する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 応答はRedirect-審判ヘッダーを含まなければなりません。 このヘッダーは、参照意識している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クライアントは、目標リソースを作動させるためにLocationヘッダーでURIに要求を再提出できます。 あるいはまた、それは「審判を向け直すのに申し込んでください」で再直接の参照リソースのURIに要求を再提出できます。 「T」ヘッダー、参照リソース自体を作動させてください。 この場合、参照リソース自体に要求を適用しなければなりません、そして、3xx応答を返してはいけません。
As redirect references do not have bodies, GET and PUT requests with "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden).
再直接の参照として、「審判を向け直すのに申し込んでください」とのボディー、GET、およびPUT要求を持たないでください。 状態403(禁じられます)に応じて、「T」は失敗しなければなりません。
Whitehead, et al. Experimental [Page 6] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[6ページ]RFC4437WebDAV
6. MKREDIRECTREF Method
6. MKREDIRECTREFメソッド
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に非ベキ等元の、そして、非安全な意味論があるとき([RFC2616]、セクション9.1を見てください)、MKREDIRECTREF要求からの応答をキャッシュしてはいけません。
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>
<!ELEMENT mkredirectref(reftarget、再直接の生涯?)><!ELEMENT reftarget(href)の>の<!のELEMENTの再直接の生涯、(永久的|、一時的である、)、永久的な>の><!ELEMENT一時的なEMPTY<!ELEMENT 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か相対的な審判のどちらかを含まなければなりません([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がありません: 再直接の生涯要素が指定されるなら、サーバが振る舞わなければならない、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-応答XML要素。 このドキュメントはMKREDIRECTREF応答ボディーのためにどんな要素も定義するのではなく、DAVを定義することに注意してください: mkredirectref-応答要素は、応答本体のために要素を定義する今後の拡大の間の相互運用性を確実にするために定義されます。
<!ELEMENT mkredirectref-response ANY>
<!ELEMENT mkredirectref-応答いずれも>。
Preconditions
前提条件
(DAV:resource-must-be-null): A resource MUST NOT exist at the
Request-URI.
(DAV:、リソースがヌルであるに違いない、)、: リソースはRequest-URIで存在してはいけません。
(DAV:parent-resource-must-be-non-null): The Request-URI minus the
last past segment MUST identify a collection.
(DAV:、親リソースが非ヌルでなければならない、)、: 最後の過去のセグメントを引いたRequest-URIは収集を特定しなければなりません。
Whitehead, et al. Experimental [Page 7] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[7ページ]RFC4437WebDAV
(DAV:name-allowed): The last segment of the Request-URI is
available for use as a resource name.
(DAV:、名前で許容される、)、: Request-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: 許されたロックされたアップデート): Request-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: サポートされた再直接の生涯): 要求本体がDAV: 再直接の生涯要素を含んでいるなら、サーバは指定された生涯をサポートしなければなりません。 DAVのサポート: DAVのサポートである間、一時的であるのは、REQUIREDです: 永久的であるのは、OPTIONALです。
(DAV:legal-reftarget): The specified is a legal URI or relative-
ref.
(DAV: 法的なreftarget): 指定は、法的なURIか相対的な審判です。
Postconditions
Postconditions
(DAV:new-redirectref): a new redirect reference resource is
created whose DAV:reftarget property has the value specified in
the request body.
(DAV: 新しいredirectref): 値が要求本体で: reftargetの特性が持っているDAVを指定した新しい再直接の参照リソースは作成されます。
6.1. Example: Creating a Redirect Reference Resource with MKREDIRECTREF
6.1. 例: MKREDIRECTREFと共に再直接の参照リソースを作成します。
>> Request:
>>要求:
MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxx
MKREDIRECTREF/~whitehead/dav/spec08.ref HTTP/1.1ホスト: www.example.comコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 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>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:mkredirectref xmlns:Dが等しい、「DAV: 「><D: reftarget><D: href>/i-d/draft webdav-プロトコル08.txt</D: href></D: reftarget></D: mkredirectref>」
>> Response:
>>応答:
HTTP/1.1 201 Created
作成されたHTTP/1.1 201
Whitehead, et al. Experimental [Page 8] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[8ページ]RFC4437WebDAV
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.
この要求はDAVによって特定されたリソースを示す http://www.example.com/~whitehead/dav/spec08.ref で新しい再直接の参照リソースの作成をもたらしました: reftargetの特性。 この例では、目標リソースはURI http://www.example.com/i-d/draft-webdav-protocol-08.txt によって特定されます。 再直接の参照リソースのDAV: resourcetypeの特性はDAV: redirectref、およびそのDAVに設定されます: 再直接の生涯の特性に、値のDAVがあります: 一時的です。
7. UPDATEREDIRECTREF Method
7. UPDATEREDIRECTREFメソッド
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に非安全な意味論があるとき([RFC2616]、セクション9.1を見てください)、UPDATEREDIRECTREF要求からの応答をキャッシュしてはいけません。
Marshalling
整理します。
The request body MUST be a DAV:updateredirectref XML element.
要求本体はDAVであるに違いありません: updateredirectref XML要素。
<!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)>
<!ELEMENT updateredirectref(reftarget?再直接の生涯ですか?)>。
See Section 6 for a definition of DAV:reftarget and DAV:redirect-
lifetime.
DAV: reftargetとDAVの定義に関してセクション6を見てください: 生涯を向け直してください。
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がありません: 再直接の生涯要素が指定されるなら、サーバは再直接の参照の生涯を変えてはいけません。
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-応答XML要素。 このドキュメントはUPDATEREDIRECTREF応答ボディーのためにどんな要素も定義するのではなく、DAVを定義することに注意してください: updateredirectref-応答要素は、応答本体のために要素を定義する今後の拡大の間の相互運用性を確実にするために定義されます。
<!ELEMENT updateredirectref-response ANY>
<!ELEMENT updateredirectref-応答いずれも>。
Whitehead, et al. Experimental [Page 9] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[9ページ]RFC4437WebDAV
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でなければならない、)、: Request-URIによって特定されたリソースはこの仕様で定義されるように再直接の参照リソースであるに違いありません。
(DAV:redirect-lifetime-supported): see Section 6.
(DAV: サポートされた再直接の生涯): セクション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: サポートされた再直接の生涯アップデート): サーバは、変化がDAVであるとサポートするかもしれません: 再直接の生涯の特性 そうしないなら、失敗に合図するのにこの条件コードを使用できます。
(DAV:legal-reftarget): see Section 6.
(DAV: 法的なreftarget): セクション6を見てください。
Postconditions
Postconditions
(DAV:redirectref-updated): the DAV:reftarget and DAV:redirect-
lifetime properties of the redirect reference have been updated
accordingly.
(DAV:、redirectrefによってアップデートされる、)、: DAV: reftargetとDAV: それに従って、再直接の参照の再直接の生涯の特性をアップデートしました。
7.1. Example: Updating a Redirect Reference Resource with
UPDATEREDIRECTREF
7.1. 例: UPDATEREDIRECTREFと共に再直接の参照リソースをアップデートします。
>> 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
UPDATEREDIRECTREF/~whitehead/dav/spec08.ref HTTP/1.1ホスト: www.example.com Applyから再直接の審判: Tコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 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>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:updateredirectref xmlns:Dが等しい、「DAV: 「><D: reftarget><D: href>/i-d/draft webdav-プロトコル08b. txt</D: href></D: reftarget></D: updateredirectref>」
>> Response:
>>応答:
HTTP/1.1 200 OK
HTTP/1.1 200OK
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-
この要求は、再直接の参照のDAV: 「/i-d/draft webdavプロトコル08b. txt」へのreftargetの特性をアップデートして、DAVを変えていません: 再直接の生涯値。 それに注意してください、「適用、-、-、再直接、-、」
Whitehead, et al. Experimental [Page 10] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[10ページ]RFC4437WebDAV
Ref" request header must be used; otherwise, the request would result in a redirect (3xx) response status.
「審判」要求ヘッダーを使用しなければなりません。 さもなければ、要求は再直接の(3xx)応答状態をもたらすでしょう。
8. Operations on Collections That Contain Redirect Reference Resources
8. 再直接の参照用の情報資源を含む収集の操作
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.
この理由で、この仕様は、「深さ」と「再直接の審判に適用してください」要求ヘッダーの間でケースバイケースで相互作用を定義して、また、自分たちでふるまいを指定しないここに言及されなかったメソッドにデフォルトを提供します。
+-------------+-----------------+------------------+-----------+
| 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" |
+-------------+-----------------+------------------+-----------+
+-------------+-----------------+------------------+-----------+ | 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.
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.
8.1. Example: PROPFIND on a Collection with Redirect Reference
Resources
8.1. Example: PROPFIND on a Collection with Redirect Reference Resources
Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here:
Suppose a PROPFIND request with Depth: infinity is submitted to the following collection, with the members shown here:
Whitehead, et al. Experimental [Page 11] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 11] RFC 4437 WebDAV Redirect Reference Resources March 2006
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
>> Request:
>> Request:
PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: F Content-Type: text/xml Content-Length: xxxx
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>
<?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:
>> Response:
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx
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>
<?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>
Whitehead, et al. Experimental [Page 12] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 12] RFC 4437 WebDAV Redirect Reference Resources March 2006
</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>
</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.)
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.)
8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
Redirect Reference Resources
8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with Redirect Reference Resources
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: infinity is submitted to the following collection, with the members shown here:
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: infinity is submitted to the following collection, with the members shown here:
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
/MyCollection/ (non-reference resource) diary.html (redirect reference resource) nunavut
>> Request:
>> Request:
PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: T Content-Type: text/xml Content-Length: xxxx
PROPFIND /MyCollection/ HTTP/1.1 Host: example.com Depth: infinity Apply-To-Redirect-Ref: T Content-Type: text/xml Content-Length: xxxx
Whitehead, et al. Experimental [Page 13] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 13] RFC 4437 WebDAV Redirect Reference Resources March 2006
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:resourcetype/>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
</D:propfind>
<?xml version="1.0" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:resourcetype/> <D:reftarget/> <D:redirect-lifetime/> </D:prop> </D:propfind>
>> Response:
>> Response:
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx
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>
<?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>
Whitehead, et al. Experimental [Page 14] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 14] RFC 4437 WebDAV Redirect Reference Resources March 2006
</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>
</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.
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.
9. Operations on Targets of Redirect Reference Resources
9. Operations on Targets of Redirect Reference Resources
Operations on targets of redirect reference resources have no effect on the reference resource.
Operations on targets of redirect reference resources have no effect on the reference resource.
10. Relative References in DAV:reftarget
10. Relative References in DAV:reftarget
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.
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.
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.
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.
Whitehead, et al. Experimental [Page 15] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 15] RFC 4437 WebDAV Redirect Reference Resources March 2006
10.1. Example: Resolving a Relative Reference in a Multi-Status
Response
10.1. Example: Resolving a Relative Reference in a Multi-Status Response
>> Request:
>> Request:
PROPFIND /geog/ HTTP/1.1 Host: example.com Apply-To-Redirect-Ref: T Depth: 1 Content-Type: text/xml Content-Length: nnn
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>
<?xml version="1.0" ?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:resourcetype/> <D:reftarget/> </D:prop> </D:propfind>
>> Response:
>> Response:
HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: nnn
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>
<?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>
Whitehead, et al. Experimental [Page 16] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 16] RFC 4437 WebDAV Redirect Reference Resources March 2006
</D:reftarget>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
</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.
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.
11. Redirect References to Collections
11. Redirect References to Collections
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:
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:
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.
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.
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.
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.
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.
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.
Whitehead, et al. Experimental [Page 17] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 17] RFC 4437 WebDAV Redirect Reference Resources March 2006
/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
/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.
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.
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.
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.
12. Headers
12. Headers
12.1. Redirect-Ref Response Header
12.1. Redirect-Ref Response Header
Redirect-Ref = "Redirect-Ref:" (URI | relative-ref) ; URI: see [RFC3986], Section 3 ; relative-ref: see [RFC3986], Section 4.2
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.
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.
Whitehead, et al. Experimental [Page 18] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 18] RFC 4437 WebDAV Redirect Reference Resources March 2006
12.2. Apply-To-Redirect-Ref Request Header
12.2. Apply-To-Redirect-Ref Request Header
Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F")
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.
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.
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.
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.
13. Redirect Reference Resource Properties
13. Redirect Reference Resource Properties
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.
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.
13.1. DAV:redirect-lifetime (protected)
13.1. DAV:redirect-lifetime (protected)
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.
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.
<!ELEMENT redirect-lifetime (permanent | temporary)> <!ELEMENT permanent EMPTY> <!ELEMENT temporary EMPTY>
<!ELEMENT redirect-lifetime (permanent | temporary)> <!ELEMENT permanent EMPTY> <!ELEMENT temporary EMPTY>
13.2. DAV:reftarget (protected)
13.2. DAV:reftarget (protected)
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.
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.
<!ELEMENT reftarget href >
<!ELEMENT reftarget href >
14. XML Elements
14. XML Elements
14.1. redirectref XML Element
14.1. redirectref XML Element
Name: redirectref
Name: redirectref
Namespace: DAV:
Namespace: DAV:
Whitehead, et al. Experimental [Page 19] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 19] RFC 4437 WebDAV Redirect Reference Resources March 2006
Purpose: Used as the value of the DAV:resourcetype property to
specify that the resource type is a redirect reference resource.
Purpose: Used as the value of the DAV:resourcetype property to specify that the resource type is a redirect reference resource.
<!ELEMENT redirectref EMPTY >
<!ELEMENT redirectref EMPTY >
15. Extensions to the DAV:response XML Element for Multi-Status
Responses
15. Extensions to the DAV:response XML Element for Multi-Status Responses
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.
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.
Consequently, the definition of the DAV:response XML element changes to the following:
Consequently, the definition of the DAV:response XML element changes to the following:
<!ELEMENT response (href, ((href*, status)|(propstat+)),
responsedescription?, location?) >
<!ELEMENT location (href) >
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?, location?) > <!ELEMENT location (href) >
16. Capability Discovery
16. Capability Discovery
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.
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.
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.
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.
16.1. Example: Discovery of Support for Redirect Reference Resources
16.1. Example: Discovery of Support for Redirect Reference Resources
>> Request:
>> Request:
OPTIONS /somecollection/someresource HTTP/1.1 Host: example.org
OPTIONS /somecollection/someresource HTTP/1.1 Host: example.org
Whitehead, et al. Experimental [Page 20] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 20] RFC 4437 WebDAV Redirect Reference Resources March 2006
>> Response:
>> 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 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, 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.
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.
17. Security Considerations
17. Security Considerations
This section is provided to make applications that implement this protocol aware of the security implications of this protocol.
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.
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.
17.1. Privacy Concerns
17.1. Privacy Concerns
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.)
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.)
17.2. Redirect Loops
17.2. Redirect Loops
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."
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."
17.3. Redirect Reference Resources and Denial of Service
17.3. Redirect Reference Resources and Denial of Service
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
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
Whitehead, et al. Experimental [Page 21] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 21] RFC 4437 WebDAV Redirect Reference Resources March 2006
of service attacks. Clients can now create redirect reference resources at heavily used sites to target locations that were not designed for heavy usage.
of service attacks. Clients can now create redirect reference resources at heavily used sites to target locations that were not designed for heavy usage.
17.4. Revealing Private Locations
17.4. Revealing Private Locations
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.
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.
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.)
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.)
This risk is no greater than the similar risk posed by HTML links.
This risk is no greater than the similar risk posed by HTML links.
18. Internationalization Considerations
18. Internationalization Considerations
All internationalization considerations mentioned in [RFC2518] also apply to this document.
All internationalization considerations mentioned in [RFC2518] also apply to this document.
19. IANA Considerations
19. IANA Considerations
All IANA considerations mentioned in [RFC2518] also apply to this document.
All IANA considerations mentioned in [RFC2518] also apply to this document.
19.1. HTTP headers
19.1. HTTP headers
This document specifies the two new HTTP headers listed below.
This document specifies the two new HTTP headers listed below.
19.1.1. Redirect-Ref
19.1.1. Redirect-Ref
Header field name: Redirect-Ref
Header field name: Redirect-Ref
Applicable protocol: http
Applicable protocol: http
Status: standard
Status: standard
Author/Change controller: IETF
Author/Change controller: IETF
Specification document: this specification (Section 12.1)
Specification document: this specification (Section 12.1)
Whitehead, et al. Experimental [Page 22] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 22] RFC 4437 WebDAV Redirect Reference Resources March 2006
19.1.2 Apply-To-Redirect-Ref
19.1.2 Apply-To-Redirect-Ref
Header field name: Apply-To-Redirect-Ref
Header field name: Apply-To-Redirect-Ref
Applicable protocol: http
Applicable protocol: http
Status: standard
Status: standard
Author/Change controller: IETF
Author/Change controller: IETF
Specification document: this specification (Section 12.2)
Specification document: this specification (Section 12.2)
20. Contributors
20. Contributors
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.
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.
21. Acknowledgements
21. Acknowledgements
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.
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.
22. Normative References
22. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[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., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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., and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
Whitehead, et al. Experimental [Page 23] RFC 4437 WebDAV Redirect Reference Resources March 2006
Whitehead, et al. Experimental [Page 23] RFC 4437 WebDAV Redirect Reference Resources March 2006
[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., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
Authors' Addresses
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
メール: ejw@cse.ucsc.edu
Geoff Clemm IBM 20 Maguire Road Lexington, MA 02421 US
ジェフクレムIBM20マグワイア・Road MA02421レキシントン(米国)
EMail: geoffrey.clemm@us.ibm.com
メール: geoffrey.clemm@us.ibm.com
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
greenbytes GmbH Hafenweg16Muenster、ジュリアンF.Reschke(エディタ)NW48155ドイツ
Phone: +49 251 2807760 Fax: +49 251 2807761 EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/
以下に電話をしてください。 +49 251 2807760Fax: +49 251 2807761 メール: julian.reschke@greenbytes.de ユリ: http://greenbytes.de/tech/webdav/
Whitehead, et al. Experimental [Page 24] RFC 4437 WebDAV Redirect Reference Resources March 2006
ホワイトヘッド、他 2006年の参照用の情報資源行進の再直接の実験的な[24ページ]RFC4437WebDAV
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Whitehead, et al. Experimental [Page 25]
ホワイトヘッド、他 実験的[25ページ]
一覧
スポンサーリンク
