Network Working Group K. Holtman
Request for Comments: 2310 TUE
Category: Experimental April 1998
Network Working Group K. Holtman
Request for Comments: 2310 TUE
Category: Experimental April 1998
The Safe Response Header Field
安全响应标头字段
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文档定义了一个名为Safe的HTTP响应头字段，可用于指示重复HTTP请求是安全的。这样的指示将允许用户代理以更用户友好的方式处理某些安全请求的重试，特别是安全POST请求。
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.
本文档定义了一个名为Safe的HTTP响应头字段，可用于指示重复HTTP请求是安全的。这样的指示将允许用户代理以更用户友好的方式处理某些安全请求的重试，特别是安全POST请求。
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符号。它使用RFC 2119中的关键词来定义每个特定需求的重要性。
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'.
根据HTTP/1.1规范[1]第9.1.1节（安全方法），POST请求默认为“不安全”`“不安全”是指“导致用户承担责任的副作用”。
It is sometimes necessary for a user agent to repeat a POST request. Examples of such cases are
用户代理有时需要重复POST请求。这类案件的例子如下：
- 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.
- 当用户在显示POST结果的同时按下RELOAD（重新加载）按钮时，当使用history（历史记录）功能重新显示已不在历史记录缓冲区中的POST结果时，重试上次尝试中给出不确定错误结果的POST请求。
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.
如果POST请求不安全，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.
如果重复的POST请求是安全的，则可以省略“用户不友好确认”对话框。然而，普通的HTTP/1.1[1]并没有一种机制可以让代理判断POST请求是否安全，默认情况下必须假定它们是不安全的。本文档向HTTP（安全头字段）添加了一种机制，用于告知POST请求是否安全。
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
通过使用“安全标头”字段，可以使需要使用安全POST请求而不是GET请求来提交web表单的web应用程序更加用户友好。使用POST请求可能有多种原因，包括
- 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.
- 表单内容可能非常大-表单用于上载文件（请参见[2]）-应用程序需要一些国际化功能（请参见[3]），这些功能仅在表单内容在请求正文中传输时可用。出于安全考虑，表单中的信息无法编码在GET请求URL中。
4 The Safe response header field
4安全响应标题字段
The Safe response header field is defined as an addition to the HTTP/1.x protocol suite.
安全响应头字段被定义为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
安全响应头字段由源服务器使用，以指示在HTTP/1.1规范[1]第9.1.1节（安全方法）的意义下，重复接收到的HTTP请求是否安全。在本规范中，如果两个请求都是HTTP请求，则HTTP请求被视为前一个请求的重复
- 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-nature
safe-nature = "yes" | "no"
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.
如果响应中缺少安全标头字段，则必须将相应的请求视为不安全，除非它是GET或HEAD请求。根据定义，GET和HEAD请求是安全的，因此用户代理应该忽略GET和HEAD响应中的“safe:no”头字段。
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.
如果根据接收到的安全报头字段，请求的重复是安全的，则可以在不请求用户确认的情况下自动重复请求。
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]。“安全标头”字段不会引入新的安全风险。
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 header字段可以提高整体安全性。
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.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[2] Nebel, E., and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[2] Nebel，E.和L.Masinter，“基于表单的HTML文件上传”，RFC 18671995年11月。
[3] Yergeau, F., Nicol, G., Adams, G., and M. Duerst, "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997.
[3] Yergeau，F.，Nicol，G.，Adams，G.，和M.Duerst，“超文本标记语言的国际化”，RFC 2070，1997年1月。
7 Author's Address
7作者地址
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands)
科恩·霍特曼埃因霍温技术大学邮政513卡默HG 6.57 5600 MB埃因霍温（荷兰）
EMail: koen@win.tue.nl
EMail: koen@win.tue.nl
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。