Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6454 Google, Inc.
Category: Standards Track December 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6454 Google, Inc.
Category: Standards Track December 2011
ISSN: 2070-1721
The Web Origin Concept
网络起源概念
Abstract
摘要
This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.
本文件定义了“来源”的概念，用户代理通常将其用作权限或特权的范围。通常，用户代理会隔离从不同来源检索的内容，以防止恶意网站操作员干扰良性网站的操作。除了概述作为源概念基础的原则外，本文档还详细介绍了如何确定URI的源以及如何将源序列化为字符串。它还定义了一个名为“Origin”的HTTP头字段，该字段指示与HTTP请求关联的源。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6454.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6454.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 4
3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 10
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 11
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 11
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 12
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 12
7. The HTTP Origin Header Field . . . . . . . . . . . . . . . . . 13
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 15
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 15
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 16
8.4. IDNA Dependency and Migration . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 4
3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 10
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 11
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 11
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 12
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 12
7. The HTTP Origin Header Field . . . . . . . . . . . . . . . . . 13
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 15
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 15
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 16
8.4. IDNA Dependency and Migration . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
User agents interact with content created by a large number of authors. Although many of those authors are well-meaning, some authors might be malicious. To the extent that user agents undertake actions based on content they process, user agent implementors might wish to restrict the ability of malicious authors to disrupt the confidentiality or integrity of other content or servers.
用户代理与大量作者创建的内容交互。尽管这些作者中有许多是善意的，但有些作者可能是恶意的。如果用户代理根据其处理的内容执行操作，用户代理实现者可能希望限制恶意作者破坏其他内容或服务器的机密性或完整性的能力。
As an example, consider an HTTP user agent that renders HTML content retrieved from various servers. If the user agent executes scripts contained in those documents, the user agent implementor might wish to prevent scripts retrieved from a malicious server from reading documents stored on an honest server, which might, for example, be behind a firewall.
举个例子，考虑HTTP用户代理，它呈现从各种服务器检索的HTML内容。如果用户代理执行这些文档中包含的脚本，则用户代理实现者可能希望防止从恶意服务器检索的脚本读取存储在诚实服务器上的文档，例如，诚实服务器可能位于防火墙后面。
Traditionally, user agents have divided content according to its "origin". More specifically, user agents allow content retrieved from one origin to interact freely with other content retrieved from that origin, but user agents restrict how that content can interact with content from another origin.
传统上，用户代理根据内容的“来源”来划分内容。更具体地说，用户代理允许从一个源检索的内容与从该源检索的其他内容自由交互，但用户代理限制该内容如何与另一个源检索的内容交互。
This document describes the principles behind the so-called same-origin policy as well as the "nuts and bolts" of comparing and serializing origins. This document does not describe all the facets of the same-origin policy, the details of which are left to other specifications, such as HTML [HTML] and WebSockets [RFC6455], because the details are often application-specific.
本文件描述了所谓的同一原产地政策背后的原则，以及比较和序列化原产地的“具体细节”。本文档没有描述同源策略的所有方面，其详细信息留给其他规范，如HTML[HTML]和WebSocket[RFC6455]，因为这些详细信息通常是特定于应用程序的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
作为算法一部分的命令式要求（如“去除任何前导空格字符”或“返回false并中止这些步骤”）应使用介绍算法时使用的关键词（“必须”、“应该”、“可能”等）的含义进行解释。
Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.
作为算法或特定步骤的一致性需求可以以任何方式实现，只要最终结果是等效的。特别是，本规范中定义的算法旨在易于理解，而不是用于执行。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号。
The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace).
根据[RFC5234]附录B.1中的定义，以下核心规则通过引用包括在内：ALPHA（字母）、CR（回车）、CRLF（CR LF）、CTL（控件）、Digital（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、LF（换行符）、OCTET（任意8位数据序列）、SP（空格）、HTAB（水平制表符）、CHAR（任何US-ASCII字符）、VCHAR（任何可见的US-ASCII字符）和WSP（空白）。
The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting the field value or forwarding the message downstream.
OWS规则用于可能出现零个或多个线性空格八位字节的情况。OWS不应生成或作为单个SP生成。在解释字段值或向下游转发消息之前，字段内容中出现的多个OWS八位组应替换为单个SP或转换为所有SP八位组（SP替换为SP以外的每个八位组）。
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).
术语“用户代理”、“客户机”、“服务器”、“代理”和“原始服务器”的含义与HTTP/1.1规范（[RFC2616]，第1.3节）中的含义相同。
A globally unique identifier is a value that is different from all other previously existing values. For example, a sufficiently long random string is likely to be a globally unique identifier. If the origin value never leaves the user agent, a monotonically increasing counter local to the user agent can also serve as a globally unique identifier.
全局唯一标识符是一个不同于所有其他以前存在的值的值。例如，足够长的随机字符串可能是全局唯一标识符。如果原始值从未离开用户代理，则用户代理本地单调递增的计数器也可以用作全局唯一标识符。
Many user agents undertake actions on behalf of remote parties. For example, HTTP user agents follow redirects, which are instructions from remote servers, and HTML user agents expose rich Document Object Model (DOM) interfaces to scripts retrieved from remote servers.
许多用户代理代表远程方执行操作。例如，HTTP用户代理遵循重定向，重定向是来自远程服务器的指令，HTML用户代理将富文档对象模型（DOM）接口公开给从远程服务器检索的脚本。
Without any security model, user agents might undertake actions detrimental to the user or to other parties. Over time, many web-related technologies have converged towards a common security model,
如果没有任何安全模型，用户代理可能会执行对用户或其他方有害的操作。随着时间的推移，许多与web相关的技术已经融合到一个通用的安全模型中，
known colloquially as the "same-origin policy". Although this security model evolved largely organically, the same-origin policy can be understood in terms of a handful of key concepts. This section presents those concepts and provides advice about how to use these concepts securely.
俗称“同一原产地政策”。尽管这种安全模型在很大程度上是有机演变的，但同源策略可以用几个关键概念来理解。本节介绍这些概念，并提供有关如何安全使用这些概念的建议。
The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:
同源策略通过URI指定信任。例如，HTML文档指定要使用URI运行的脚本：
<script src="https://example.com/library.js"></script>
<script src="https://example.com/library.js"></script>
When a user agent processes this element, the user agent will fetch the script at the designated URI and execute the script with the privileges of the document. In this way, the document grants all the privileges it has to the resource designated by the URI. In essence, the document declares that it trusts the integrity of information retrieved from that URI.
当用户代理处理此元素时，用户代理将在指定的URI获取脚本，并以文档的权限执行脚本。通过这种方式，文档将其拥有的所有特权授予URI指定的资源。本质上，文档声明它信任从该URI检索的信息的完整性。
In addition to importing libraries from URIs, user agents also send information to remote parties designated by URI. For example, consider the HTML form element:
除了从URI导入库之外，用户代理还向URI指定的远程方发送信息。例如，考虑HTML表单元素：
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
When the user enters his or her password and submits the form, the user agent sends the password to the network endpoint designated by the URI. In this way, the document exports its secret data to that URI, in essence declaring that it trusts the confidentiality of information sent to that URI.
当用户输入密码并提交表单时，用户代理将密码发送到URI指定的网络端点。通过这种方式，文档将其机密数据导出到该URI，实质上声明它信任发送到该URI的信息的机密性。
When designing new protocols that use the same-origin policy, make sure that important trust distinctions are visible in URIs. For example, if both Transport Layer Security (TLS) and non-TLS protected resources use the "http" URI scheme (as in [RFC2817]), a document would be unable to specify that it wishes to retrieve a script only over TLS. By using the "https" URI scheme, documents are able to indicate that they wish to interact with resources that are protected from active network attackers.
在设计使用同源策略的新协议时，请确保重要的信任区别在URI中可见。例如，如果传输层安全性（TLS）和非TLS保护的资源都使用“http”URI方案（如[RFC2817]中所示），则文档将无法指定它希望仅通过TLS检索脚本。通过使用“https”URI方案，文档能够表明它们希望与受主动网络攻击者保护的资源进行交互。
In principle, user agents could treat every URI as a separate protection domain and require explicit consent for content retrieved from one URI to interact with another URI. Unfortunately, this design is cumbersome for developers because web applications often consist of a number of resources acting in concert.
原则上，用户代理可以将每个URI视为单独的保护域，并要求明确同意从一个URI检索的内容与另一个URI交互。不幸的是，这种设计对开发人员来说很麻烦，因为web应用程序通常由许多协同工作的资源组成。
Instead, user agents group URIs together into protection domains called "origins". Roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.)
相反，用户代理将URI分组到称为“源”的保护域中。粗略地说，如果两个URI具有相同的方案、主机和端口，则它们是相同来源的一部分（即，表示相同的主体）。（有关详细信息，请参见第4节。）
Q: Why not just use the host?
问：为什么不直接使用主机呢？
A: Including the scheme in the origin tuple is essential for security. If user agents did not include the scheme, there would be no isolation between http://example.com and https://example.com because the two have the same host. However, without this isolation, an active network attacker could corrupt content retrieved from http://example.com and have that content instruct the user agent to compromise the confidentiality and integrity of content retrieved from https://example.com, bypassing the protections afforded by TLS [RFC5246].
答：在源元组中包含方案对于安全性至关重要。如果用户代理不包括该方案，那么它们之间就不会有隔离http://example.com 和https://example.com 因为这两个主机是一样的。但是，如果没有这种隔离，主动网络攻击者可能会损坏从中检索到的内容http://example.com 并让该内容指示用户代理损害从中检索的内容的机密性和完整性https://example.com，绕过TLS提供的保护[RFC5246]。
Q: Why use the fully qualified host name instead of just the "top-level" domain?
问：为什么要使用完全限定的主机名，而不仅仅是“顶级”域？
A: Although the DNS has hierarchical delegation, the trust relationships between host names vary by deployment. For example, at many educational institutions, students can host content at https://example.edu/~student/, but that does not mean a document authored by a student should be part of the same origin (i.e., inhabit the same protection domain) as a web application for managing grades hosted at https://grades.example.edu/.
答：虽然DNS具有分层委托，但主机名之间的信任关系因部署而异。例如，在许多教育机构，学生可以在https://example.edu/~student/，但这并不意味着学生编写的文档应与管理位于的成绩的web应用程序具有相同的来源（即，位于相同的保护域）https://grades.example.edu/.
The example.edu deployment illustrates that grouping resources by origin does not always align perfectly with every deployment scenario. In this deployment, every student's web site inhabits the same origin, which might not be desirable. In some sense, the origin granularity is a historical artifact of how the security model evolved.
example.edu部署说明，按来源对资源进行分组并不总是与每个部署场景完全一致。在这个部署中，每个学生的网站都位于同一个源站点，这可能是不可取的。从某种意义上说，源粒度是安全模型演变的历史产物。
All of the following resources have the same origin:
以下所有资源都具有相同的来源：
http://example.com/
http://example.com:80/
http://example.com/path/file
http://example.com/
http://example.com:80/
http://example.com/path/file
Each of the URIs has the same scheme, host, and port components.
每个URI都有相同的方案、主机和端口组件。
Each of the following resources has a different origin from the others.
以下每个资源都有不同于其他资源的来源。
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
In each case, at least one of the scheme, host, and port component will differ from the others in the list.
在每种情况下，方案、主机和端口组件中至少有一个与列表中的其他组件不同。
Although user agents group URIs into origins, not every resource in an origin carries the same authority (in the security sense of the word "authority", not in the [RFC3986] sense). For example, an image is passive content and, therefore, carries no authority, meaning the image has no access to the objects and resources available to its origin. By contrast, an HTML document carries the full authority of its origin, and scripts within (or imported into) the document can access every resource in its origin.
尽管用户代理将URI分组到源中，但并非源中的每个资源都具有相同的权限（在“权限”一词的安全意义上，而不是在[RFC3986]意义上）。例如，图像是被动内容，因此不具有权限，这意味着图像无法访问其来源可用的对象和资源。相比之下，HTML文档拥有其源文件的全部权限，文档中（或导入到文档中）的脚本可以访问其源文件中的所有资源。
User agents determine how much authority to grant a resource by examining its media type. For example, resources with a media type of image/png are treated as images, and resources with a media type of text/html are treated as HTML documents.
用户代理通过检查资源的媒体类型来确定授予资源的权限。例如，媒体类型为image/png的资源被视为图像，媒体类型为text/html的资源被视为html文档。
When hosting untrusted content (such as user-generated content), web applications can limit that content's authority by restricting its media type. For example, serving user-generated content as image/png is less risky than serving user-generated content as text/html. Of course, many web applications incorporate untrusted content in their HTML documents. If not done carefully, these applications risk leaking their origin's authority to the untrusted content, a vulnerability commonly known as cross-site scripting.
当托管不受信任的内容（如用户生成的内容）时，web应用程序可以通过限制其媒体类型来限制该内容的权限。例如，将用户生成的内容作为图像/png提供比将用户生成的内容作为文本/html提供风险更小。当然，许多web应用程序在其HTML文档中包含不受信任的内容。如果不小心操作，这些应用程序可能会将其来源的权限泄露给不受信任的内容，这是一个通常称为跨站点脚本的漏洞。
When designing new pieces of the web platform, be careful not to grant authority to resources irrespective of media type. Many web applications serve untrusted content with restricted media types. A new web platform feature that grants authority to these pieces of content risks introducing vulnerabilities into existing applications. Instead, prefer to grant authority to media types that already possess the origin's full authority or to new media types designed specifically to carry the new authority.
在设计新的web平台时，请注意不要向资源授予权限，而不管媒体类型如何。许多web应用程序使用受限制的媒体类型提供不受信任的内容。一个新的web平台功能为这些内容授予权限，可能会将漏洞引入现有应用程序。相反，您更愿意将权限授予已经拥有源站完全权限的媒体类型，或者授予专门设计用于承载新权限的新媒体类型。
In order to remain compatible with servers that supply incorrect media types, some user agents employ "content sniffing" and treat content as if it had a different media type than the media type supplied by the server. If not done carefully, content sniffing can lead to security vulnerabilities because user agents might grant low-authority media types, such as images, the privileges of high-authority media types, such as HTML documents [SNIFF].
为了与提供不正确媒体类型的服务器保持兼容，一些用户代理使用“内容嗅探”并将内容视为与服务器提供的媒体类型不同的媒体类型。如果不小心执行，内容嗅探可能会导致安全漏洞，因为用户代理可能会授予低权限媒体类型（如图像）和高权限媒体类型（如HTML文档[SNIFF]）的权限。
Generally speaking, user agents isolate different origins and permit controlled communication between origins. The details of how user agents provide isolation and communication vary depending on several factors.
一般来说，用户代理隔离不同的来源并允许来源之间的受控通信。用户代理如何提供隔离和通信的细节取决于几个因素。
Most objects (also known as application programming interfaces or APIs) exposed by the user agent are available only to the same origin. Specifically, content retrieved from one URI can access objects associated with content retrieved from another URI if, and only if, the two URIs belong to the same origin, e.g., have the same scheme, host, and port.
用户代理公开的大多数对象（也称为应用程序编程接口或API）仅对同一来源可用。具体地说，从一个URI检索的内容可以访问与从另一个URI检索的内容相关联的对象，如果且仅当两个URI属于相同的源，例如，具有相同的方案、主机和端口。
There are some exceptions to this general rule. For example, some parts of HTML's Location interface are available across origins (e.g., to allow for navigating other browsing contexts). As another example, HTML's postMessage interface is visible across origins explicitly to facilitate cross-origin communication. Exposing objects to foreign origins is dangerous and should be done only with great care because doing so exposes these objects to potential attackers.
这条一般规则有一些例外。例如，HTML位置界面的某些部分可以跨源访问（例如，允许导航其他浏览上下文）。另一个例子是，HTML的postMessage接口在源代码之间是可见的，以便于跨源代码通信。将对象暴露于外来源是危险的，因此必须非常小心，因为这样做会将这些对象暴露给潜在的攻击者。
Access to network resources varies depending on whether the resources are in the same origin as the content attempting to access them.
对网络资源的访问取决于资源是否与试图访问它们的内容位于同一来源。
Generally, reading information from another origin is forbidden. However, an origin is permitted to use some kinds of resources retrieved from other origins. For example, an origin is permitted to execute script, render images, and apply style sheets from any origin. Likewise, an origin can display content from another origin, such as an HTML document in an HTML frame. Network resources can also opt into letting other origins read their information, for example, using Cross-Origin Resource Sharing [CORS]. In these cases, access is typically granted on a per-origin basis.
通常，禁止从其他来源读取信息。但是，允许一个来源使用从其他来源检索的某些资源。例如，允许原点从任何原点执行脚本、渲染图像和应用样式表。同样，一个源可以显示来自另一个源的内容，例如HTML框架中的HTML文档。网络资源也可以选择让其他来源读取其信息，例如，使用跨来源资源共享[CORS]。在这些情况下，访问权限通常是基于每个来源授予的。
Sending information to another origin is permitted. However, sending information over the network in arbitrary formats is dangerous. For this reason, user agents restrict documents to sending information using particular protocols, such as in an HTTP request without custom headers. Expanding the set of allowed protocols, for example, by adding support for WebSockets, must be done carefully to avoid introducing vulnerabilities [RFC6455].
允许向其他来源发送信息。然而，通过网络以任意格式发送信息是危险的。因此，用户代理将文档限制为使用特定协议发送信息，例如在没有自定义头的HTTP请求中。扩展允许的协议集，例如，通过添加对WebSocket的支持，必须小心进行，以避免引入漏洞[RFC6455]。
Whenever user agents allow one origin to interact with resources from another origin, they invite security issues. For example, the ability to display images from another origin leaks their height and width. Similarly, the ability to send network requests to another origin gives rise to cross-site request forgery vulnerabilities [CSRF]. However, user agent implementors often balance these risks against the benefits of allowing the cross-origin interaction. For example, an HTML user agent that blocked cross-origin network requests would prevent its users from following hyperlinks, a core feature of the web.
每当用户代理允许一个源与另一个源的资源交互时，它们就会引发安全问题。例如，显示来自另一个原点的图像会泄漏其高度和宽度。类似地，向另一个来源发送网络请求的能力会导致跨站点请求伪造漏洞[CSRF]。然而，用户代理实现者通常会平衡这些风险和允许跨源交互的好处。例如，阻止跨源网络请求的HTML用户代理将阻止其用户跟踪超链接，这是web的核心功能。
When adding new functionality to the web platform, it can be tempting to grant a privilege to one resource but to withhold that privilege from another resource in the same origin. However, withholding privileges in this way is ineffective because the resource without the privilege can usually obtain the privilege anyway because user agents do not isolate resources within an origin. Instead, privileges should be granted or withheld from origins as a whole (rather than discriminating between individual resources within an origin) [BOFGO].
在向web平台添加新功能时，很可能会向一个资源授予特权，但从同一来源的另一个资源保留该特权。但是，以这种方式保留特权是无效的，因为没有特权的资源通常可以获得特权，因为用户代理不会隔离源中的资源。相反，特权应该从整个起源地被授予或保留（而不是在一个起源地内的单个资源之间进行歧视）[BOFGO]。
The same-origin policy uses URIs to designate trust relationships. URIs are grouped together into origins, which represent protection domains. Some resources in an origin (e.g., active content) are granted the origin's full authority, whereas other resources in the origin (e.g., passive content) are not granted the origin's authority. Content that carries its origin's authority is granted access to objects and network resources within its own origin. This content is also granted limited access to objects and network resources of other origins, but these cross-origin privileges must be designed carefully to avoid security vulnerabilities.
同源策略使用URI指定信任关系。URI被分组到代表保护域的源中。源中的某些资源（例如，主动内容）被授予源的完全权限，而源中的其他资源（例如，被动内容）未被授予源的权限。具有源站权限的内容被授予访问其源站内的对象和网络资源的权限。此内容还被授予对其他来源的对象和网络资源的有限访问权限，但必须仔细设计这些跨来源权限以避免安全漏洞。
The origin of a URI is the value computed by the following algorithm:
URI的来源是通过以下算法计算的值：
1. If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value.
1. 如果URI未使用分层元素作为命名机构（请参见[RFC3986]，第3.2节），或者如果URI不是绝对URI，则生成新的全局唯一标识符并返回该值。
NOTE: Running this algorithm multiple times for the same URI can produce different values each time. Typically, user agents compute the origin of, for example, an HTML document once and use that origin for subsequent security checks rather than recomputing the origin for each security check.
注意：对同一URI多次运行此算法可能每次产生不同的值。通常，用户代理只计算一次HTML文档的来源，并将该来源用于后续安全检查，而不是为每次安全检查重新计算来源。
2. Let uri-scheme be the scheme component of the URI, converted to lowercase.
2. 让uri scheme作为uri的scheme组件，转换为小写。
3. If the implementation doesn't support the protocol given by uri-scheme, then generate a fresh globally unique identifier and return that value.
3. 如果实现不支持uri方案给出的协议，则生成一个新的全局唯一标识符并返回该值。
4. If uri-scheme is "file", the implementation MAY return an implementation-defined value.
4. 如果uri方案为“文件”，则实现可能返回实现定义的值。
NOTE: Historically, user agents have granted content from the file scheme a tremendous amount of privilege. However, granting all local files such wide privileges can lead to privilege escalation attacks. Some user agents have had success granting local files directory-based privileges, but this approach has not been widely adopted. Other user agents use globally unique identifiers for each file URI, which is the most secure option.
注意：历史上，用户代理为文件方案中的内容授予了大量特权。但是，授予所有本地文件如此广泛的权限可能会导致权限升级攻击。一些用户代理已成功授予本地文件基于目录的权限，但这种方法尚未被广泛采用。其他用户代理为每个文件URI使用全局唯一标识符，这是最安全的选项。
5. Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]).
5. 让uri主机作为uri的主机组件，转换为小写（使用[RFC4790]中定义的i；ascii casemap排序规则）。
NOTE: This document assumes that the user agent performs Internationalizing Domain Names in Applications (IDNA) processing and validation when constructing the URI. In particular, this document assumes the uri-host will contain only LDH labels because the user agent will have already converted any non-ASCII labels to their corresponding A-labels (see [RFC5890]). For this reason, origin-based security policies are sensitive to the IDNA algorithm employed by the user agent. See Section 8.4 for further discussion.
注意：本文档假设用户代理在构造URI时执行应用程序中的域名国际化（IDNA）处理和验证。特别是，本文档假设uri主机将仅包含LDH标签，因为用户代理已将任何非ASCII标签转换为相应的A标签（请参见[RFC5890]）。因此，基于源的安全策略对用户代理使用的IDNA算法非常敏感。进一步讨论见第8.4节。
6. If there is no port component of the URI:
6. 如果URI没有端口组件：
1. Let uri-port be the default port for the protocol given by uri-scheme.
1. 让uri端口成为uri方案给出的协议的默认端口。
Otherwise:
否则：
2. Let uri-port be the port component of the URI.
2. 让uri端口成为uri的端口组件。
7. Return the triple (uri-scheme, uri-host, uri-port).
7. 返回三元组（uri方案、uri主机、uri端口）。
Two origins are "the same" if, and only if, they are identical. In particular:
当且仅当两个原点相同时，它们才是“相同的”。特别地：
o If the two origins are scheme/host/port triples, the two origins are the same if, and only if, they have identical schemes, hosts, and ports.
o 如果两个源是scheme/host/port三元组，则当且仅当它们具有相同的方案、主机和端口时，这两个源是相同的。
o An origin that is a globally unique identifier cannot be the same as an origin that is a scheme/host/port triple.
o 全局唯一标识符的原点不能与方案/主机/端口三元组的原点相同。
Two URIs are same-origin if their origins are the same.
如果两个URI的来源相同，则它们是相同的来源。
NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [RFC2397] is not same-origin with itself because data URIs do not use a server-based naming authority and therefore have globally unique identifiers as origins.
注意：URI不一定与它本身是同一来源。例如，数据URI[RFC2397]与其自身的来源不同，因为数据URI不使用基于服务器的命名机构，因此具有全局唯一标识符作为来源。
This section defines how to serialize an origin to a unicode [Unicode6] string and to an ASCII [RFC20] string.
本节定义如何将原点序列化为unicode[Unicode6]字符串和ASCII[RFC20]字符串。
The unicode-serialization of an origin is the value returned by the following algorithm:
原点的unicode序列化是以下算法返回的值：
1. If the origin is not a scheme/host/port triple, then return the string
1. 如果源不是scheme/host/port三元组，则返回字符串
null
无效的
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
（即代码点序列U+006E、U+0075、U+006C、U+006C）并中止这些步骤。
2. Otherwise, let result be the scheme part of the origin triple.
2. 否则，将结果设为原点三元组的方案部分。
3. Append the string "://" to result.
3. 将字符串“：/”附加到结果。
4. Append each component of the host part of the origin triple (converted as follows) to the result, separated by U+002E FULL STOP code points ("."):
4. 将原始三元组的主体部分的每个组件（转换如下）附加到结果中，以U+002E句号代码点（“.”）分隔：
1. If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]).
1. 如果组件是A标签，则使用相应的U标签（请参阅[RFC5890]和[RFC5891]）。
2. Otherwise, use the component verbatim.
2. 否则，请使用组件逐字记录。
5. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:
5. 如果原始三元组的端口部分与原始三元组的方案部分给出的协议的默认端口不同：
1. Append a U+003A COLON code point (":") and the given port, in base ten, to result.
1. 将一个U+003A冒号代码点（“：”）和给定的端口（以十为底）追加到结果中。
6. Return result.
6. 返回结果。
The ascii-serialization of an origin is the value returned by the following algorithm:
原点的ascii序列化是以下算法返回的值：
1. If the origin is not a scheme/host/port triple, then return the string
1. 如果源不是scheme/host/port三元组，则返回字符串
null
无效的
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
（即代码点序列U+006E、U+0075、U+006C、U+006C）并中止这些步骤。
2. Otherwise, let result be the scheme part of the origin triple.
2. 否则，将结果设为原点三元组的方案部分。
3. Append the string "://" to result.
3. 将字符串“：/”附加到结果。
4. Append the host part of the origin triple to result.
4. 将原始三元组的主体部分附加到结果。
5. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:
5. 如果原始三元组的端口部分与原始三元组的方案部分给出的协议的默认端口不同：
1. Append a U+003A COLON code point (":") and the given port, in base ten, to result.
1. 将一个U+003A冒号代码点（“：”）和给定的端口（以十为底）追加到结果中。
6. Return result.
6. 返回结果。
This section defines the HTTP Origin header field.
本节定义HTTP源标题字段。
The Origin header field has the following syntax:
“原始标头”字段具有以下语法：
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC 3986
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC 3986
When included in an HTTP request, the Origin header field indicates the origin(s) that "caused" the user agent to issue the request, as defined by the API that triggered the user agent to issue the request.
当包含在HTTP请求中时，Origin header字段表示“导致”用户代理发出请求的源，如触发用户代理发出请求的API所定义。
For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request.
例如，考虑一个代表原点执行脚本的用户代理。如果这些脚本中的一个导致用户代理发出HTTP请求，则用户代理可以使用Origin header字段通知服务器当脚本导致用户代理发出请求时脚本正在执行的安全上下文。
In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent MAY list all the origins in the Origin header field. For example, if the HTTP request was initially issued by one origin but then later
在某些情况下，许多源代码导致用户代理发出HTTP请求。在这些情况下，用户代理可以在源标题字段中列出所有源。例如，如果HTTP请求最初是由一个源发出的，但后来又发出了
redirected by another origin, the user agent MAY inform the server that two origins were involved in causing the user agent to issue the request.
通过另一个来源重定向，用户代理可以通知服务器，导致用户代理发出请求涉及两个来源。
The user agent MAY include an Origin header field in any HTTP request.
用户代理可以在任何HTTP请求中包括源报头字段。
The user agent MUST NOT include more than one Origin header field in any HTTP request.
用户代理在任何HTTP请求中不得包含多个源标头字段。
Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in the Origin header field.
每当用户代理从“隐私敏感”上下文发出HTTP请求时，该用户代理必须在源标题字段中发送值“null”。
NOTE: This document does not define the notion of a privacy-sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin header fields.
注意：本文档未定义隐私敏感上下文的概念。生成HTTP请求的应用程序可以将上下文指定为隐私敏感，以限制用户代理如何生成源标头字段。
When generating an Origin header field, the user agent MUST meet the following requirements:
生成源标题字段时，用户代理必须满足以下要求：
o Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.
o 语法中的每个序列化源产品都必须是源的ascii序列化。
o No two consecutive serialized-origin productions in the grammar can be identical. In particular, if the user agent would generate two consecutive serialized-origins, the user agent MUST NOT generate the second one.
o 语法中没有两个连续的序列化源产品可以相同。特别是，如果用户代理将生成两个连续的序列化源，则用户代理不得生成第二个。
The same-origin policy is one of the cornerstones of security for many user agents, including web browsers. Historically, some user agents tried other security models, including taint tracking and exfiltration prevention, but those models proved difficult to implement at the time (although there has been recent interest in reviving some of these ideas).
同源策略是许多用户代理（包括web浏览器）安全的基石之一。从历史上看，一些用户代理尝试了其他安全模型，包括污染跟踪和过滤预防，但这些模型在当时很难实现（尽管最近人们对恢复其中一些想法很感兴趣）。
Evaluating the security of the same-origin policy is difficult because the origin concept itself plays such a central role in the security landscape. The notional origin itself is just a unit of isolation, imperfect as are most one-size-fits-all notions. That said, there are some systemic weaknesses, discussed below.
评估同源策略的安全性是困难的，因为源概念本身在安全环境中起着如此重要的作用。概念起源本身只是一个孤立的单位，与大多数一刀切的概念一样不完美。尽管如此，仍存在一些系统性弱点，如下所述。
In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities. If the DNS is partially or fully compromised, the same-origin policy might fail to provide the security properties required by applications.
实际上，同源策略依赖于域名系统（DNS）来实现安全性，因为许多常用的URI方案（如http）使用基于DNS的命名机构。如果DNS部分或完全受损，则同源策略可能无法提供应用程序所需的安全属性。
Some URI schemes, such as https, are more resistant to DNS compromise because user agents employ other mechanisms, such as certificates, to verify the source of content retrieved from these URIs. Other URI schemes, such as the chrome-extension URI scheme (see Section 4.3 of [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise.
一些URI方案（如https）更能抵抗DNS危害，因为用户代理使用其他机制（如证书）来验证从这些URI检索的内容源。其他URI方案，如chrome扩展URI方案（见[CRX]第4.3节），使用基于公钥的命名机构，并且完全安全，不受DNS危害。
The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.
web源概念隔离了从不同URI方案检索的内容；这对于遏制DNS危害的影响至关重要。
Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.
随着时间的推移，许多技术已经融合到web源概念上，作为一种方便的隔离单元。然而，今天使用的许多技术，如cookies[RFC6265]，都比现代网络起源概念更早。这些技术通常具有不同的隔离单元，从而导致漏洞。
One alternative is to use only the "registry-controlled" domain rather than the fully qualified domain name as the unit of isolation (e.g., "example.com" instead of "www.example.com"). This practice is problematic for a number of reasons and is NOT RECOMMENDED:
一种替代方法是仅使用“注册表控制”域而不是完全限定的域名作为隔离单元（例如，“example.com”而不是“www.example.com”）。由于多种原因，这种做法存在问题，不建议采用：
1. The notion of a "registry-controlled" domain is a function of human practice surrounding the DNS rather than a property of the DNS itself. For example, many municipalities in Japan run public registries quite deep in the DNS hierarchy. There are widely used "public suffix lists", but these lists are difficult to keep up to date and vary between implementations.
1. “注册表控制”域的概念是围绕DNS的人类实践的功能，而不是DNS本身的属性。例如，日本的许多城市在DNS层次结构中运行相当深的公共注册。有广泛使用的“公共后缀列表”，但这些列表很难保持最新，并且在不同的实现中有所不同。
2. This practice is incompatible with URI schemes that do not use a DNS-based naming authority. For example, if a given URI scheme uses public keys as naming authorities, the notion of a "registry-controlled" public key is somewhat incoherent. Worse, some URI schemes, such as nntp, use dotted delegation in the opposite direction from DNS (e.g., alt.usenet.kooks), and others use the DNS but present the labels in the reverse of the usual order (e.g., com.example.www).
2. 这种做法与不使用基于DNS的命名机构的URI方案不兼容。例如，如果给定的URI方案使用公钥作为命名权限，“注册表控制”公钥的概念有些不一致。更糟糕的是，一些URI方案，如nntp，使用与DNS相反方向的虚线委托（例如alt.usenet.kooks），而另一些使用DNS，但以与通常相反的顺序显示标签（例如com.example.www）。
At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities.
充其量，使用“注册表控制”域是特定于URI方案和实现的。最坏的情况是，URI方案和实现之间的差异可能导致漏洞。
When using the same-origin policy, user agents grant authority to content based on its URI rather than based on which objects the content can designate. This disentangling of designation from authority is an example of ambient authority and can lead to vulnerabilities.
使用同源策略时，用户代理根据内容的URI而不是内容可以指定的对象来授予内容权限。这种指定与权威的分离是环境权威的一个例子，可能导致漏洞。
Consider, for example, cross-site scripting in HTML documents. If an attacker can inject script content into an HTML document, those scripts will run with the authority of the document's origin, perhaps allowing the script access to sensitive information, such as the user's medical records. If, however, the script's authority were limited to those objects that the script could designate, the attacker would not gain any advantage by injecting the script into an HTML document hosted by a third party.
例如，在HTML文档中考虑跨站点脚本。如果攻击者可以将脚本内容注入HTML文档，则这些脚本将以文档源的权限运行，可能允许脚本访问敏感信息，例如用户的医疗记录。但是，如果脚本的权限仅限于脚本可以指定的对象，则攻击者将脚本注入由第三方托管的HTML文档中不会获得任何优势。
The security properties of the same-origin policy can depend crucially on details of the IDNA algorithm employed by the user agent. In particular, a user agent might map some international domain names (for example, those involving the U+00DF character) to different ASCII representations depending on whether the user agent uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].
同源策略的安全属性在很大程度上取决于用户代理使用的IDNA算法的细节。具体而言，用户代理可能会根据用户代理使用的是IDNA2003[RFC3490]还是IDNA2008[RFC5890]，将一些国际域名（例如，涉及U+00DF字符的域名）映射到不同的ASCII表示。
Migrating from one IDNA algorithm to another might redraw a number of security boundaries, potentially erecting new security boundaries or, worse, tearing down security boundaries between two mutually distrusting entities. Changing security boundaries is risky because combining two mutually distrusting entities into the same origin might allow one to attack the other.
从一个IDNA算法迁移到另一个IDNA算法可能会重新划定许多安全边界，可能会建立新的安全边界，或者更糟糕的是，会破坏两个相互不信任的实体之间的安全边界。更改安全边界是有风险的，因为将两个相互不信任的实体合并到同一个源中可能会允许一个攻击另一个。
The permanent message header field registry (see [RFC3864]) has been updated with the following registration:
永久消息头字段注册表（请参见[RFC3864]）已更新为以下注册：
Header field name: Origin
标题字段名称：来源
Applicable protocol: http
适用协议：http
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification (Section 7)
规范文件：本规范（第7节）
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]Newman，C.，Duerst，M.，和A.Gulbrandsen，“互联网应用协议整理注册表”，RFC 47902007年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[Unicode6] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", 2011, <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode 6]Unicode联盟，“Unicode标准，版本6.0.0”，2011年<http://www.unicode.org/versions/Unicode6.0.0/>.
[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", 2008, <http://w2spconf.com/2008/papers/s2p1.pdf>.
[BOFGO]Jackson，C.和A.Barth，“小心更细粒度的起源”，2008年<http://w2spconf.com/2008/papers/s2p1.pdf>.
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/2010/WD-cors-20100727/>.
[CORS]van Kesteren，A.，“跨来源资源共享”，W3C工作草案WD-CORS-20100727，2010年7月<http://www.w3.org/TR/2010/WD-cors-20100727/>.
Latest version available at <http://www.w3.org/TR/cors/>.
最新版本可于<http://www.w3.org/TR/cors/>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, "Protecting Browsers from Extension Vulnerabilities", 2010, <http://www.isoc.org/isoc/conferences/ndss/10/pdf/ 04.pdf>.
[CRX]Barth，A.，Feel，A.，Saxena，P.，和A.Boodman，“保护浏览器免受扩展漏洞的影响”，2010年<http://www.isoc.org/isoc/conferences/ndss/10/pdf/ 04.pdf>。
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[CSRF]Barth，A.，Jackson，C.，和J.Mitchell，“跨站点请求伪造的强大防御”，2008年<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5- 20110525, May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
[HTML]希克森，I.，“HTML5”，W3C工作草案WD-HTML5-201105252011年5月<http://www.w3.org/TR/2011/WD-html5-20110525/>.
Latest version available at <http://www.w3.org/TR/html5/>.
最新版本可于<http://www.w3.org/TR/html5/>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397]Masinter，L.“数据”URL方案”，RFC 2397，1998年8月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 64552011年12月。
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", Work in Progress, May 2011.
[嗅探]Barth，A.和I.Hickson，“媒体类型嗅探”，正在进行的工作，2011年5月。
We would like to thank Lucas Adamski, Stephen Farrell, Miguel A. Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable feedback on this document.
我们要感谢卢卡斯·亚当斯基、斯蒂芬·法雷尔、米格尔·加西亚、托比亚斯·冈德罗姆、伊恩·希克森、安妮·范·凯斯特伦、杰夫·霍奇斯、柯林·杰克逊、拉里·马斯滕、阿列克西·梅尔尼科夫、马克·诺丁汉、朱利安·雷什克、彼得·圣安德烈、乔纳斯·西金、希德·斯塔姆、丹尼尔·维迪兹和克里斯·韦伯对本文件的宝贵反馈。
Author's Address
作者地址
Adam Barth Google, Inc.
亚当·巴特谷歌公司。
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/