RFC2310 日本語訳

Network Working Group                                          K. Holtman
Request for Comments: 2310                                            TUE
Category: Experimental                                         April 1998

Holtmanがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2310年の火曜日のカテゴリ: 実験的な1998年4月

                     The Safe Response Header Field

安全な応答ヘッダーフィールド

Status of this Memo

この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 (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   This document defines a HTTP response header field called Safe, which
   can be used to indicate that repeating a HTTP request is safe.  Such
   an indication will allow user agents to handle retries of some safe
   requests, in particular safe POST requests, in a more user-friendly
   way.

このドキュメントはHTTP要求を繰り返すのが安全であることを示すのに使用できるSafeと呼ばれるHTTP応答ヘッダーフィールドを定義します。 ユーザエージェントはそのような指示でいくつかの安全な要求の再試行を扱うことができるでしょう、特定の安全なポストの要求で、よりユーザフレンドリーな方法で。

1 Introduction

1つの序論

   This document defines a HTTP response header field called Safe, which
   can be used to indicate that repeating a HTTP request is safe.  Such
   an indication will allow user agents to handle retries of some safe
   requests, in particular safe POST requests, in a more user-friendly
   way.

このドキュメントはHTTP要求を繰り返すのが安全であることを示すのに使用できるSafeと呼ばれるHTTP応答ヘッダーフィールドを定義します。 ユーザエージェントはそのような指示でいくつかの安全な要求の再試行を扱うことができるでしょう、特定の安全なポストの要求で、よりユーザフレンドリーな方法で。

2 Terminology and Notation

2 用語と記法

   This document uses the HTTP terminology and BNF notation defined in
   [1].  It uses the key words in RFC 2119 for defining the significance
   of each particular requirement.

このドキュメントは[1]で定義されたHTTP用語とBNF記法を使用します。 それは、それぞれの特定の要件の意味を定義するのにRFC2119のキーワードを使用します。

3 Rationale

3 原理

   According to Section 9.1.1 (Safe Methods) of the HTTP/1.1
   specification [1], POST requests are assumed to be `unsafe' by
   default.  `Unsafe' means `causes side effects for which the user will
   be held accountable'.

.1のセクション9.1HTTP/1.1仕様[1](安全なMethods)に従って、ポストの要求がデフォルトで'危険である'と思われます。 '危険な'手段'はユーザが責任があるように保たれる副作用を引き起こします'。

Holtman                       Experimental                      [Page 1]

RFC 2310             The Safe Response Header Field           April 1998

安全なHoltmanの実験的な[1ページ]RFC2310の応答ヘッダ分野1998年4月

   It is sometimes necessary for a user agent to repeat a POST request.
   Examples of such cases are

ユーザエージェントがポストの要求を繰り返すのが時々必要です。 そのような場合に関する例はそうです。

     - when retrying a POST request which gave an indeterminate error
       result in the previous attempt
     - when the user presses the RELOAD button while a POST result is
       displayed
     - when the history function is used to redisplay a POST result
       which is no longer in the history buffer.

- 再試行するとき。

   If the POST request is unsafe, HTTP requires explicit user
   confirmation is before the request is repeated.  The confirmation
   dialog often takes the form of a `repost form data?'  dialog box.
   This dialog is confusing to many users, and slows down navigation in
   any case.

ポストの要求が危険であるなら、HTTPは明白なユーザ確認を必要とします。要求が繰り返される前にあります。 確認対話はしばしば'フォームデータを再び投函してくれますか?'ダイアログボックスの形を取ります。 この対話は、多くのユーザに混乱させていて、どのような場合でも、ナビゲーションを減速させます。

   If the repeated POST request is safe, the user-unfriendly
   confirmation dialog can be omitted.  However plain HTTP/1.1 [1] has
   no mechanism by which agents can tell if POST requests are safe, and
   they must be assumed unsafe by default.  This document adds a
   mechanism to HTTP, the Safe header field, for telling if a POST
   request is safe.

繰り返されたポストの要求が安全であるなら、ユーザ無愛想な確認対話を省略できます。 しかしながら、明瞭なHTTP/1.1[1]には、ポストの要求が安全であるなら、エージェントが言うことができるメカニズムが全くありません、そして、危険であるとデフォルトでそれらを思わなければなりません。 このドキュメントはHTTP、ポストの要求が安全であるかどうか言うためのSafeヘッダーフィールドにメカニズムを加えます。

   Using the Safe header field, web applications which require the use
   of a safe POST request, rather than a GET request, for the submission
   of web forms, can be made more user-friendly.  The use of a POST
   request may be required for a number of reasons, including

Safeヘッダーフィールドを使用して、GET要求よりむしろ安全なポストの要求のウェブフォームの提出の使用を必要とするウェブアプリケーションはさらにユーザフレンドリーにすることができます。 ポストの要求の使用が多くの理由、包含に必要であるかもしれません。

     - the contents of the form are potentially very large
     - the form is used to upload a file (see [2])
     - the application needs some internationalization features
       (see [3]) which are only available if the form contents are
       transmitted in a request body the information in the form cannot
       be encoded in a GET request URL because of security
       considerations.

- フォームの中身は潜在的に非常に大きいです--フォームがファイルをアップロードするのに使用される、((フォームコンテンツが要求本体で伝えられて、セキュリティ問題のためにGET要求URLでフォームでの情報をコード化できないということであるなら、[3]) どれが利用可能であるだけであるかを見てください。

4 The Safe response header field

4 Safe応答ヘッダーフィールド

   The Safe response header field is defined as an addition to the
   HTTP/1.x protocol suite.

Safe応答ヘッダーフィールドはHTTP/1.xプロトコル群への追加と定義されます。

   The Safe response header field is used by origin servers to indicate
   whether repeating the received HTTP request is safe in the sense of
   Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1].  For
   the purpose of this specification, a HTTP request is considered to be
   a repetition of a previous request if both requests

Safe応答ヘッダーフィールドは発生源サーバによって使用されて、受信されたHTTP要求を繰り返すのが.1のセクション9.1HTTP/1.1仕様[1](安全なMethods)の意味で安全であるかどうかを示します。 この仕様の目的のために、HTTP要求は両方の要求であるなら前の要求の反復であると考えられます。

Holtman                       Experimental                      [Page 2]

RFC 2310             The Safe Response Header Field           April 1998

安全なHoltmanの実験的な[2ページ]RFC2310の応答ヘッダ分野1998年4月

     - are issued by the same user agent, and
     - apply to the same resource, and
     - have the same request method, and
     - both have no request body, or both have request bodies which are
       byte-wise identical after decoding of any content and transfer
       codings.

- そして、そして、そして、同じユーザエージェントによって発行される、--同じリソースに適用してください、--同じ要求メソッドを持ってください、--要求本体が全くないか、両方が、どんな内容も解読した後にバイト同じ状態で的な要求本体を持って、コーディングを移します。

   The Safe header field has the following syntax.

Safeヘッダーフィールドには、以下の構文があります。

     Safe        = "Safe" ":" safe-nature
     safe-nature = "yes" | "no"

「安全な=「金庫」」:、」 安全な自然の安全な自然は「はい」と等しいです。| 「いいえ」

   An example of the header field is:

ヘッダーフィールドに関する例は以下の通りです。

     Safe: yes

金庫: はい

   If a Safe header field is absent in the response, the corresponding
   request MUST be considered unsafe, unless it is a GET or HEAD
   request.  As GET and HEAD requests are safe by definition, user
   agents SHOULD ignore a `Safe: no' header field in GET and HEAD
   responses.

Safeヘッダーフィールドが応答で欠けるなら、危険であると対応する要求を考えなければなりません、それがGETかHEAD要求でないなら。 GETとHEAD要求が定義上安全であるので、ユーザエージェントSHOULDは'金庫を無視します:、' GETとHEAD応答におけるヘッダーフィールドでない。

   If, according to a received Safe header field, the repeating of a
   request is safe, the request MAY be repeated automatically without
   asking for user confirmation.

容認されたSafeヘッダーフィールドに従って要求の反復が安全であるなら、ユーザ確認を求めないで、要求は自動的に繰り返されるかもしれません。

5 Security Considerations

5 セキュリティ問題

   For a discussion of the security considerations connected to HTTP
   form submission, see [1].  The Safe header field introduces no new
   security risks.

HTTPフォーム提案に関連づけられたセキュリティ問題の議論に関しては、[1]を見てください。 Safeヘッダーフィールドはどんな新しいセキュリティ危険も導入しません。

   The use of GET requests for form submission has some security risks
   which are absent for submission with other HTTP methods.  By taking
   away a counter-incentive to the use of GET requests for form
   submission, the Safe header field may improve overall security.

GET要求のフォーム服従の使用には、いくつかの服従において、他のHTTPメソッドで欠けているセキュリティリスクがあります。 GET要求のフォーム服従の使用にカウンタ誘因を持ち去ることによって、Safeヘッダーフィールドは総合的なセキュリティを向上させるかもしれません。

Holtman                       Experimental                      [Page 3]

RFC 2310             The Safe Response Header Field           April 1998

安全なHoltmanの実験的な[3ページ]RFC2310の応答ヘッダ分野1998年4月

6 References

6つの参照箇所

   [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and
   T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",  RFC
   2068, January 1997.

[1] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」

   [2] Nebel, E., and L. Masinter, "Form-based File Upload in HTML",
   RFC 1867, November 1995.

[2]Nebel、E.、およびL.Masinter、「HTMLにおけるフォームベースのファイルアップロード」、RFC1867、1995年11月。

   [3] Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
   "Internationalization of the Hypertext Markup Language", RFC
   2070, January 1997.

1997年1月の[3]YergeauとF.とニコルとG.とアダムス、G.とM.Duerst、「ハイパーテキストマークアップランゲージの国際化」RFC2070。

7 Author's Address

7作者のアドレス

   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (The Netherlands)

クンHoltman Technische UniversiteitアイントホーフェンPostbus513のKamer HGの6.57 5600MBのアイントホーフェン(オランダ)

   EMail: koen@win.tue.nl

メール: koen@win.tue.nl

Holtman                       Experimental                      [Page 4]

RFC 2310             The Safe Response Header Field           April 1998

安全なHoltmanの実験的な[4ページ]RFC2310の応答ヘッダ分野1998年4月

8.  Full Copyright Statement

8. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Holtman                       Experimental                      [Page 5]

Holtman実験的です。[5ページ]