原文 https://tools.ietf.org/html/rfc6797
警告狞玛，文章很枯燥，也沒(méi)什么內(nèi)容
大體意思就是服務(wù)器和客戶端都遵循一些行為模式涧窒，
在服務(wù)器端是聲明自己是HSTS
在客戶端有一個(gè)聲明HSTS的檢查列表
大家通過(guò)HSTS交互心肪，一句話就是能轉(zhuǎn)https的就把http轉(zhuǎn)https，如果發(fā)現(xiàn)任何問(wèn)題就報(bào)錯(cuò)纠吴，中斷鏈接等等
編號(hào)及提出者
Internet Engineering Task Force (IETF) Request for Comments: 6797
Category: Standards Track
ISSN: 2070-1721
J. Hodges PayPal C. Jackson Carnegie Mellon University A. Barth
摘要
Abstract
HTTP Strict Transport Security (HSTS)
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.
描述了一個(gè)只通過(guò)安全鏈接的上網(wǎng)機(jī)制
接下來(lái)是一些版權(quán)信息和目錄硬鞍，跳過(guò)
1.簡(jiǎn)介
HTTP [RFC2616] may be used over various transports, typically the Transmission Control Protocol (TCP). However, TCP does not provide channel integrity protection, confidentiality, or secure host identification. Thus, the Secure Sockets Layer (SSL) protocol [RFC6101] and its successor, Transport Layer Security (TLS) [RFC5246] were developed in order to provide channel-oriented security and are typically layered between application protocols and TCP. [RFC2818] specifies how HTTP is layered onto TLS and defines the Uniform Resource Identifier (URI) scheme of "https" (in practice, however, HTTP user agents (UAs) typically use either TLS or SSL3, depending upon a combination of negotiation with the server and user preferences).
意思是說(shuō)https（屬于應(yīng)用層）是在tcp（屬于傳輸層）上為了解決信息完整，信息機(jī)密，身份認(rèn)證問(wèn)題的協(xié)議固该。
ps: UAS, user agents 指的是用戶上網(wǎng)的身份锅减，包含瀏覽器，系統(tǒng)等一些附加信息
UAs employ various local security policies with respect to the characteristics of their interactions with web resources, depending on (in part) whether they are communicating with a given web resource’s host using HTTP or HTTP-over-Secure-Transport. For example, cookies ([RFC6265]) may be flagged as Secure. UAs are to send such Secure cookies to their addressed host only over a secure transport. This is in contrast to non-Secure cookies, which are returned to the host regardless of transport (although subject to other rules).
UAs行為多種多樣伐坏，舉了個(gè)cookies的例子
UAs typically announce to their users any issues with secure connection establishment, such as being unable to validate a TLS server certificate trust chain, or if a TLS server certificate is expired, or if a TLS host’s domain name appears incorrectly in the TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs enable users to elect to continue to interact with a web resource’s host in the face of such issues. This behavior is sometimes referred to as "click(ing) through" security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]; thus, it can be described as "click-through insecurity".
UAs 回提示一些安全問(wèn)題怔匣，比如網(wǎng)站證書過(guò)期，或者網(wǎng)站域名和證書里記載的對(duì)不上桦沉。這時(shí)候會(huì)通知用戶每瞒，不過(guò)用戶可以選擇繼續(xù)訪問(wèn)，這個(gè)問(wèn)題叫做 click-through insecurity 繼續(xù)點(diǎn)擊產(chǎn)生的不安全
A key vulnerability enabled by click-through insecurity is the leaking of any cookies the web resource may be using to manage a user’s session. The threat here is that an attacker could obtain the cookies and then interact with the legitimate web resource while impersonating the user.
這種行為的最大的問(wèn)題是泄露了cookies纯露，從而使得攻擊者有可能偽造用戶身份去訪問(wèn)互聯(lián)網(wǎng)資源
Jackson and Barth proposed an approach, in [ForceHTTPS], to enable web resources to declare that any interactions by UAs with the web resource must be conducted securely and that any issues with establishing a secure transport session are to be treated as fatal and without direct user recourse. The aim is to prevent click- through insecurity and address other potential threats.
Jackson和Barth提出了ForceHTTPS剿骨，意思就是任何不對(duì)勁就不讓繼續(xù)訪問(wèn)，防止了click-through insecurity
This specification embodies and refines the approach proposed in [ForceHTTPS]. For example, rather than using a cookie to convey policy from a web resource’s host to a UA, it defines an HTTP response header field for this purpose. Additionally, a web resource’s host may declare its policy to apply to the entire domain name subtree rooted at its host name. This enables HTTP Strict Transport Security (HSTS) to protect so-called "domain cookies", which are applied to all subdomains of a given web resource’s host name.
在這里實(shí)現(xiàn)并改進(jìn)了ForceHTTPS苔埋，改進(jìn)點(diǎn)包括使用HTTP響應(yīng)頭的數(shù)據(jù)來(lái)完成cookie的工作懦砂。另外，網(wǎng)站可以聲明域名樹(shù)组橄，把策略用于所有子域名荞膘，這個(gè)東西叫 domain cookie
This specification also incorporates notions from [JacksonBarth2008] in that policy is applied on an "entire-host" basis: it applies to HTTP (only) over any TCP port of the issuing host.
Note that the policy defined by this specification is distinctly different than the "same-origin policy" defined in "The Web Origin Concept" [RFC6454]. These differences are summarized in Appendix B.
說(shuō)HSTS使用了不太一樣的策略，和同源策略（same-origin policy）有出入玉工，見(jiàn)附錄B
2.綜述
開(kāi)頭幾個(gè)小節(jié)沒(méi)什么內(nèi)容羽资，略過(guò)
2.3 威脅模型
HSTS is concerned with three threat classes: passive network attackers, active network attackers, and imperfect web developers. However, it is explicitly not a remedy for two other classes of threats: phishing and malware. Threats that are addressed, as well as threats that are not addressed, are briefly discussed below.
Readers may wish to refer to Section 2 of [ForceHTTPS] for details as well as relevant citations.
HSTS關(guān)注三類安全問(wèn)題，被動(dòng)網(wǎng)絡(luò)攻擊遵班，主動(dòng)網(wǎng)絡(luò)攻擊和網(wǎng)絡(luò)應(yīng)用不完善屠升，并不解決網(wǎng)絡(luò)釣魚(yú)和惡意軟件的問(wèn)題。
2.3.1.1 被動(dòng)網(wǎng)絡(luò)攻擊
When a user browses the web on a local wireless network (e.g., an
802.11-based wireless local area network) a nearby attacker can
possibly eavesdrop on the user’s unencrypted Internet Protocol-based
connections, such as HTTP, regardless of whether or not the local
wireless network itself is secured [BeckTews09]. Freely available
wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive
eavesdropping attacks, even if the local wireless network is
operating in a secure fashion. A passive network attacker using such
tools can steal session identifiers/cookies and hijack the user’s web
session(s) by obtaining cookies containing authentication credentials
[ForceHTTPS]. For example, there exist widely available tools, such
as Firesheep (a web browser extension) [Firesheep], that enable their
wielder to obtain other local users’ session cookies for various web
applications.
在本地?zé)o線網(wǎng)的用戶有可能被攻擊者監(jiān)聽(tīng)未加密的網(wǎng)絡(luò)鏈接狭郑，比如http腹暖，有一系列工具可供攻擊者使用
To mitigate such threats, some web sites support, but usually do not
force, access using end-to-end secure transport -- e.g., signaled
through URIs constructed with the "https" scheme [RFC2818]. This can
lead users to believe that accessing such services using secure
transport protects them from passive network attackers.
Unfortunately, this is often not the case in real-world deployments,
as session identifiers are often stored in non-Secure cookies to
permit interoperability with versions of the service offered over
insecure transport ("Secure cookies" are those cookies containing the
"Secure" attribute [RFC6265]). For example, if the session
identifier for a web site (an email service, say) is stored in a
non-Secure cookie, it permits an attacker to hijack the user’s
session if the user’s UA makes a single insecure HTTP request to the
site.
為了緩和攻擊，一些網(wǎng)站采用了https翰萨，但是在部署的時(shí)候經(jīng)常會(huì)把包含session信息保存在不安全的cookies中
2.3.1.2 主動(dòng)網(wǎng)絡(luò)攻擊
A determined attacker can mount an active attack, either by
impersonating a user’s DNS server or, in a wireless network, by
spoofing network frames or offering a similarly named evil twin
access point. If the user is behind a wireless home router, an
attacker can attempt to reconfigure the router using default
passwords and other vulnerabilities. Some sites, such as banks, rely
on end-to-end secure transport to protect themselves and their users
from such active attackers. Unfortunately, browsers allow their
users to easily opt out of these protections in order to be usable
for sites that incorrectly deploy secure transport, for example by
generating and self-signing their own certificates (without also
distributing their certification authority (CA) certificate to their
users’ browsers).
列舉了個(gè)主動(dòng)攻擊的方法
2.3.1.3 網(wǎng)站部署和bug
The security of an otherwise uniformly secure site (i.e., all of its
content is materialized via "https" URIs) can be compromised
completely by an active attacker exploiting a simple mistake, such as
the loading of a cascading style sheet or a SWF (Shockwave Flash)
movie over an insecure connection (both cascading style sheets and
SWF movies can script the embedding page, to the surprise of many web
developers, plus some browsers do not issue so-called "mixed content
warnings" when SWF files are embedded via insecure connections).
Even if the site’s developers carefully scrutinize their login page
for "mixed content", a single insecure embedding anywhere on the
overall site compromises the security of their login page because an
attacker can script (i.e., control) the login page by injecting code
(e.g., a script) into another, insecurely loaded, site page.
如果網(wǎng)站的部署者不小心脏答，為css或者swf提供了不安全鏈接的加載，攻擊者可以在其中安插腳本
2.3.2 不在解決范圍的問(wèn)題
網(wǎng)絡(luò)釣魚(yú)
Phishing attacks occur when an attacker solicits authentication
credentials from the user by hosting a fake site located on a
different domain than the real site, perhaps driving traffic to the
fake site by sending a link in an email message. Phishing attacks
can be very effective because users find it difficult to distinguish
the real site from a fake site. HSTS is not a defense against
phishing per se; rather, it complements many existing phishing
defenses by instructing the browser to protect session integrity and
long-lived authentication tokens [ForceHTTPS].
HSTS不解決這個(gè)問(wèn)題亩鬼，依賴于瀏覽器去識(shí)別
惡意軟件和瀏覽器缺陷
Because HSTS is implemented as a browser security mechanism, it
relies on the trustworthiness of the user’s system to protect the
session. Malicious code executing on the user’s system can
compromise a browser session, regardless of whether HSTS is used.
也不解決這個(gè)問(wèn)題殖告，因?yàn)椴辉谝粋€(gè)層面上
2.4 前提條件（實(shí)施HSTS的）
核心要求
Web sites need to be able to declare to UAs that they should be
accessed using a strict security policy.
- 網(wǎng)站需要能告知UAs，必須使用嚴(yán)格安全策略
Web sites need to be able to instruct UAs that contact them
insecurely to do so securely.
- 網(wǎng)站應(yīng)該安全地給出用戶“不安全上網(wǎng)”的指示（比較迷惑）
UAs need to retain persistent data about web sites that signal
strict security policy enablement, for time spans declared by the
web sites. Additionally, UAs need to cache the "freshest" strict
security policy information, in order to allow web sites to
update the information.
- UAs應(yīng)該保存一個(gè)關(guān)于實(shí)施了嚴(yán)格安全策略的網(wǎng)站的列表雳锋，并能更新
UAs need to rewrite all insecure UA "http" URI loads to use the
"https" secure scheme for those web sites for which secure policy
is enabled.
4.UAs應(yīng)該把http請(qǐng)求重寫為https請(qǐng)求（針對(duì)執(zhí)行嚴(yán)格安全策略的網(wǎng)站）
Web site administrators need to be able to signal strict security
policy application to subdomains of higher-level domains for
which strict security policy is enabled, and UAs need to enforce
such policy.
For example, both example.com and foo.example.com could set
policy for bar.foo.example.com.
- 網(wǎng)站應(yīng)該對(duì)次級(jí)域名同樣使用嚴(yán)格安全策略黄绩，UAs應(yīng)該強(qiáng)化這種行為，例如
example.com 或 foo.example.com 應(yīng)該能對(duì) bar.foo.example.com 同樣實(shí)施嚴(yán)格安全策略
UAs need to disallow security policy application to peer domains,
and/or higher-level domains, by domains for which strict security
policy is enabled.
For example, neither bar.foo.example.com nor foo.example.com can
set policy for example.com, nor can bar.foo.example.com set
policy for foo.example.com. Also, foo.example.com cannot set
policy for sibling.example.com.
6.UAs不應(yīng)該用于對(duì)等（或上級(jí)和平級(jí)）域名實(shí)施安全策略玷过，比如bar.foo.example.com或foo.example.com不能對(duì)example.com實(shí)施安全策略爽丹，另外筑煮，foo.example.com也不能對(duì)sibling.example.com實(shí)施安全策略
UAs need to prevent users from "clicking through" security
warnings. Halting connection attempts in the face of secure
transport exceptions is acceptable. See also Section 12.1 ("No
User Recourse").
- UAs應(yīng)該防止用戶clicking through，終止鏈接也是可取的
額外要求
Disallow "mixed security context" loads
- 不允許混合安全內(nèi)容加載
Facilitate user declaration of web sites for which strict
security policy is enabled, regardless of whether the sites
signal HSTS Policy.
- 教育用戶
3. 一致性標(biāo)準(zhǔn)
A conformant host is one that implements all the requirements listed
in this specification that are applicable to hosts.
A conformant user agent is one that implements all the requirements
listed in this specification that are applicable to user agents.
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].
意思就是網(wǎng)站和客戶端都得完全實(shí)現(xiàn)列出的條件
4. 術(shù)語(yǔ)习劫，略過(guò)
5. HSTS原理綜述
5.1 聲明為HSTS網(wǎng)站
An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS
Policy, which is represented by and conveyed via the
Strict-Transport-Security HTTP response header field over secure
transport (e.g., TLS). Upon error-free receipt and processing of
this header by a conformant UA, the UA regards the host as a Known
HSTS Host.
通過(guò)HTSTS響應(yīng)頭部區(qū)域來(lái)聲明
5.2 HSTS策略
An HSTS Policy directs UAs to communicate with a Known HSTS Host only
over secure transport and specifies policy retention time duration.
HSTS Policy explicitly overrides the UA processing of URI references,
user input (e.g., via the "location bar"), or other information that,
in the absence of HSTS Policy, might otherwise cause UAs to
communicate insecurely with the Known HSTS Host.
An HSTS Policy may contain an optional directive -- includeSubDomains
-- specifying that this HSTS Policy also applies to any hosts whose
domain names are subdomains of the Known HSTS Host’s domain name.
HSTS策略指引UAs只通過(guò)HSTS策略的方式和網(wǎng)站進(jìn)行交互咆瘟，改變UAs的行為，同樣對(duì)次級(jí)域名產(chǎn)生作用
5.3 HSTS策略在UAs的存儲(chǔ)和維護(hù)
UAs store and index HSTS Policies based strictly upon the domain
names of the issuing HSTS Hosts.
This means that UAs will maintain the HSTS Policy of any given HSTS
Host separately from any HSTS Policies issued by any other HSTS Hosts
whose domain names are superdomains or subdomains of the given HSTS
Host’s domain name. Only the given HSTS Host can update or can cause
deletion of its issued HSTS Policy. It accomplishes this by sending
Strict-Transport-Security HTTP response header fields to UAs with new
values for policy time duration and subdomain applicability. Thus,
UAs cache the "freshest" HSTS Policy information on behalf of an HSTS
Host. Specifying a zero time duration signals the UA to delete the
HSTS Policy (including any asserted includeSubDomains directive) for
that HSTS Host. See Section 8.1 ("Strict-Transport-Security Response
Header Field Processing") for details. Additionally, Section 6.2
presents examples of Strict-Transport-Security HTTP response header
fields.
一些細(xì)節(jié)
5.4 UAs對(duì)HSTS的執(zhí)行
When establishing an HTTP connection to a given host, however
instigated, the UA examines its cache of Known HSTS Hosts to see if
there are any with domain names that are superdomains of the given
host’s domain name. If any are found, and of those if any have the
includeSubDomains directive asserted, then HSTS Policy applies to the
given host. Otherwise, HSTS Policy applies to the given host only if
the given host is itself known to the UA as an HSTS Host. See
Section 8.3 ("URI Loading and Port Mapping") for details.
檢查一下和自己進(jìn)行鏈接的網(wǎng)站的域名的上級(jí)域名是否在UAs的列表中诽里，如果是袒餐，那么認(rèn)為次級(jí)域名也是HSTS的
6. 語(yǔ)法
This section defines the syntax of the Strict-Transport-Security HTTP
response header field and its directives, and presents some examples.
Section 7 ("Server Processing Model") then details how hosts employ
this header field to declare their HSTS Policy, and Section 8 ("User
Agent Processing Model") details how user agents process the header
field and apply the HSTS Policy.
這節(jié)開(kāi)始講語(yǔ)法
6.1 HSTS響應(yīng)頭
The Strict-Transport-Security HTTP response header field (STS header
field) indicates to a UA that it MUST enforce the HSTS Policy in
regards to the host emitting the response message containing this
header field.
The ABNF (Augmented Backus-Naur Form) syntax for the STS header field
is given below. It is based on the Generic Grammar defined in
Section 2 of [RFC2616] (which includes a notion of "implied linear
whitespace", also known as "implied *LWS").
Strict-Transport-Security = "Strict-Transport-Security" ":"
[ directive ] *( ";" [ directive ] )
directive = directive-name [ "=" directive-value ]
directive-name = token
directive-value = token | quoted-string
where:
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
一些語(yǔ)法的表達(dá)方式及變種
The two directives defined in this specification are described below.
The overall requirements for directives are:
- The order of appearance of directives is not significant.
- All directives MUST appear only once in an STS header field.
Directives are either optional or required, as stipulated in
their definitions.- Directive names are case-insensitive.
- UAs MUST ignore any STS header field containing directives, or
other header field value data, that does not conform to the
syntax defined in this specification.- If an STS header field contains directive(s) not recognized by
the UA, the UA MUST ignore the unrecognized directives, and if
the STS header field otherwise satisfies the above requirements
(1 through 4), the UA MUST process the recognized directives.
Additional directives extending the semantic functionality of the STS
header field can be defined in other specifications, with a registry
(having an IANA policy definition of IETF Review [RFC5226]) defined
for them at such time.
一些細(xì)節(jié)，比如STS header field在響應(yīng)頭中順序無(wú)關(guān)谤狡，大小寫無(wú)關(guān)灸眼，只能出現(xiàn)一次等等
6.1.1 存活時(shí)間，就是UAs標(biāo)記網(wǎng)站為HSTS網(wǎng)站的時(shí)間
6.1.2 是否包含次級(jí)域名 （includeSubDomains）
6.2 一些例子
Strict-Transport-Security: max-age="31536000"
Strict-Transport-Security: max-age=0
Strict-Transport-Security: max-age=0; includeSubDomains
7 服務(wù)器處理模型
7.1響應(yīng)HTTPS請(qǐng)求
When replying to an HTTP request that was conveyed over a secure
transport, an HSTS Host SHOULD include in its response message an STS
header field that MUST satisfy the grammar specified above in
Section 6.1 ("Strict-Transport-Security HTTP Response Header Field").
If an STS header field is included, the HSTS Host MUST include only
one such header field.
Establishing a given host as a Known HSTS Host, in the context of a
given UA, MAY be accomplished over HTTP, which is in turn running
over secure transport, by correctly returning (per this
specification) at least one valid STS header field to the UA. Other
mechanisms, such as a client-side pre-loaded Known HSTS Host list,
MAY also be used; e.g., see Section 12 ("User Agent Implementation
Advice").
意思就是響應(yīng)帶著STS header field來(lái)聲明自己是HSTS網(wǎng)站
7.2 響應(yīng)HTTP請(qǐng)求
If an HSTS Host receives an HTTP request message over a non-secure
transport, it SHOULD send an HTTP response message containing a
status code indicating a permanent redirect, such as status code 301
(Section 10.3.2 of [RFC2616]), and a Location header field value
containing either the HTTP request’s original Effective Request URI
(see Section 9 ("Constructing an Effective Request URI")) altered as
necessary to have a URI scheme of "https", or a URI generated
according to local policy with a URI scheme of "https".
意思就是要么報(bào)錯(cuò)301要么直接轉(zhuǎn)成https
8 UAs處理模型
8.1 處理STS響應(yīng)頭部
If an HTTP response, received over a secure transport, includes an
STS header field, conforming to the grammar specified in Section 6.1
("Strict-Transport-Security HTTP Response Header Field"), and there
are no underlying secure transport errors or warnings (see
Section 8.4), the UA MUST either:
o Note the host as a Known HSTS Host if it is not already so noted
(see Section 8.1.1 ("Noting an HSTS Host - Storage Model")),
or
o Update the UA’s cached information for the Known HSTS Host if
either or both of the max-age and includeSubDomains header field
value tokens are conveying information different than that already
maintained by the UA.
The max-age value is essentially a "time to live" value relative
to the reception time of the STS header field.
If the max-age header field value token has a value of zero, the
UA MUST remove its cached HSTS Policy information (including the
includeSubDomains directive, if asserted) if the HSTS Host is
known, or the UA MUST NOT note this HSTS Host if it is not yet
known.
If a UA receives more than one STS header field in an HTTP
response message over secure transport, then the UA MUST process
only the first such header field.
Otherwise:
o If an HTTP response is received over insecure transport, the UA
MUST ignore any present STS header field(s).
o The UA MUST ignore any STS header fields not conforming to the
grammar specified in Section 6.1 ("Strict-Transport-Security HTTP
Response Header Field").
一些細(xì)節(jié)墓懂，涉及標(biāo)記網(wǎng)站為HSTS焰宣，更新緩存，存活時(shí)間和如果發(fā)現(xiàn)網(wǎng)站沒(méi)有按策略行事就忽略STS頭部的存在
以下幾節(jié)都是在講細(xì)節(jié)捕仔，通過(guò)名稱就能看出在干什么
8.1.1 標(biāo)記為HSTS網(wǎng)站
8.2 網(wǎng)站域名匹配（和以知HSTS列表對(duì)比s）
8.3 URI加載和端口映射
8.4 錯(cuò)誤處理
8.5 忽略<meta>里面的STS設(shè)置
8.6 響應(yīng)缺失STS
9 組裝有效的請(qǐng)求URI
This section specifies how an HSTS Host must construct the Effective
Request URI for a received HTTP request.
HTTP requests often do not carry an absoluteURI for the target
resource; instead, the URI needs to be inferred from the Request-URI,
Host header field, and connection context ([RFC2616], Sections 3.2.1,
5.1.2, and 5.2). The result of this process is called the "effective
request URI (ERU)". The "target resource" is the resource identified
by the effective request URI.
意思就是一般情況下請(qǐng)求的URI要被推斷為“有效的URI”（ERU）匕积，才能獲取資源，這個(gè)小節(jié)就是講如何組裝的
9.1 ERU 基礎(chǔ)定義
The first line of an HTTP request message, Request-Line, is specified
by the following ABNF from [RFC2616], Section 5.1:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
The Request-URI, within the Request-Line, is specified by the
following ABNF from [RFC2616], Section 5.1.2:
Request-URI = "*" | absoluteURI | abs_path | authority
The Host request header field is specified by the following ABNF from
[RFC2616], Section 14.23:
Host = "Host" ":" host [ ":" port ]
其實(shí)就是域名+端口這樣的形式
9.2 判定是否是ERU
If the Request-URI is an absoluteURI, then the effective request URI
is the Request-URI.
If the Request-URI uses the abs_path form or the asterisk form, and
the Host header field is present, then the effective request URI is
constructed by concatenating:
o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over a TLS/
SSL-secured TCP connection, and
o the octet sequence "://", and
o the host, and the port (if present), from the Host header field,
and
o the Request-URI obtained from the Request-Line, unless the
Request-URI is just the asterisk "*".
If the Request-URI uses the abs_path form or the asterisk form, and
the Host header field is not present, then the effective request URI
is undefined.
Otherwise, when Request-URI uses the authority form, the effective
request URI is undefined.
Effective request URIs are compared using the rules described in
[RFC2616] Section 3.2.3, except that empty path components MUST NOT
be treated as equivalent to an absolute path of "/".
一些細(xì)節(jié)
