Upgrade Insecure Requests （日本語訳）

1. 序論

作者には、自身による~siteや~appを，~secureでない~transportから離れて，暗号化されかつ認証された接続へ移行0することが、ますます奨励されている `WEB-HTTPS$r 。この移行には，作者, 利用者~双方にとり有意な利点があるが、負な副作用もないわけではない。 ◎ Increasingly, we encourage authors to transition their sites and applications away from insecure transport, and onto encrypted and authenticated connections [WEB-HTTPS]. While this migration has significant advantages for both authors and users, it isn’t without negative side-effects.

【この仕様の “作者（ author ）” は、 ~page内容の作者というより，~site管理者（~serverの環境設定の作者）を指している。】

特に，混在~内容の検査-法 `MIX$r は、相当~量の旧来の内容を ~HTTPSに移動する~~仕事を抱える管理者たちにとって，悩みの種になり得る。古い内容を読み通して，資源~URLを手作業で書直すには、かなりの手間がかかる。さらには、［ BBC ~siteの~archive `BBC-ARCHIVE$r や, New York Times の直書きされた~URL `NYT-HTTPS$r ］を考えればわかるように、真に旧来の内容は，更新-が困難あるいは不可能なこともざらにある。 ◎ Most notably, mixed content checking [MIX] has the potential to cause real headache for administrators tasked with moving substantial amounts of legacy content onto HTTPS. In particular, going through old content and rewriting resource URLs manually is a huge undertaking. Moreover, it’s often the case that truly legacy content is difficult or impossible to update. Consider the BBC’s archived websites [BBC-ARCHIVE], or the New York Times' hard-coded URLs [NYT-HTTPS].

この負担は、 ~site作者から除去されるべきである — ［ ~siteは~secureな資源のみ読込むことを意図していて，~secureでない~URLは等価な~secureな~URLに置換されたかのように扱われるべきである］ことを，作者が~UAに表明できるようにすることにより。 ◎ We should remove this burden from site authors by allowing them to assert to a user agent that they intend a site to load only secure resources, and that insecure URLs ought to be treated as though they had been replaced with equivalent secure URLs.

この文書は、新たな ~CSP 指令 `upgrade-insecure-requests$dir を定義する。作者は、この指令を通して，上述について表明できる。この施策は~headerとして送達されることに注意。これにより、管理者は，~source~codeを個別に触れることなく，~pageの集合を`昇格の仕組み$に容易に~opt-intoできるようになる。施策を~HTMLの中に~inline化するような~approach†では、上述した旧来の内容などには~~対処できないであろう。 ◎ This document defines a new Content Security Policy directive, upgrade-insecure-requests, through which authors can make this assertion. Note: Delivering the policy as a header allows an administrator to easily opt a set of pages into the upgrade mechanism without touching their source code individually. The legacy content examples above would not be feasible with an approach that inlined the policy into HTML, for example.

【† とは言え、 `meta^e `要素~内に~inline化＠~CSP3#meta-element$して送達された場合に無視されるわけではないであろう。】

1.1. 目標

包括的な目標は、［混在~内容の阻止-法 `MIX$r による負な副作用を抑制する］ことにより，~siteを~secureでない生成元から移行する際の負担を抑制することである。 ◎ The overarching goal is to reduce the burden of migrating websites from insecure origins by reducing the negative side effects of mixed content blocking [MIX].

作者が次を行うものと見做す下で… ◎ If we assume that authors do＼

~server側で準備作業を済ませておく（証明書を得する／ ~serverを環境設定する／ ~redirectを設定しておく） ◎ the server-side legwork (obtaining a certificate, configuring the server, setting up redirects),＼
［当事者-主体, 第三者-主体］どちらの内容も，~secureな`~scheme$url上の【~secureでない~scheme上のそれと】 `同じ^em ( `~host$url, `~path$url ) 組で~access可能になるのを確保する ◎ and that authors also ensure that both first- and third-party content is accessible at the same host and path on a secure scheme,＼

…この特能が実装されたならば、次が成立するべきである： ◎ then the following statements ought to hold after implementing this feature:

作者は、所与の~pageから要請されるすべての内容が，成功裡かつ~secureに読込まれることを確保できるべきである。混在~内容を阻止して~secureな生成元へ移行した結果，~pageを非互換化するべきでない。 ◎ Authors should be able to ensure that all content requested by a given page loads successfully, and securely. Mixed content blocking should not break pages as a result of migrating to a secure origin.

注記： `混在~内容^cite の`厳密~mode$は、この要件を`満たさない^em — それが表明するのは、逆の性格の様な何かである。 ◎ Note: This requirement is not met by Mixed Content’s strict mode, which makes something like the opposite assertion.
~UAは、前項の結果として，要請している混在~内容に関係するどの~security指示子も格下げするべきでない — どのような~secureでない内容も要請されないべきである。 ◎ As a result of #1, the user agent should not degrade any security indicators related to requesting mixed content, as no insecure content should be requested.
作者は、すべての内部~linkが，利用者にとって ~siteの~secureな~addressへ — 移行前の~secureでない~addressではなく — 正しく送信されることを確保できるべきである。 ◎ Authors should be able to ensure that all internal links correctly send users to the site’s secure address, and not to its pre-migration insecure address.
作者は、 ~siteの内容を編集せずに，以上の目標すべてを達成できるべきである。このことは、［保守が~~相応に困難で, 昇格などまったく~~想定されてない，~archiveされた内容や旧来の~system ］にとって，特に重要である。 ◎ Authors should be able to achieve all these goals without editing a site’s content. This is particularly important for archived content and legacy systems for which maintenance is difficult enough, never mind upgrades.
作者は、［ `昇格の仕組み$を~supportする~clientには~secureな資源を~serveするしつつ， ~supportしない~clientに対しても~secureでない資源を~serveし続ける］ことで，~secureでないから~secureへの移行0を~~継続的に行えるべきである。 ◎ Authors should be able to pursue a gradual transition from insecure to secure, serving secure resources to clients that support upgrades, while retaining insecure resources for clients that don’t.

注記：ここに定義される`昇格の仕組み$は、 Strict Transport Security `RFC6797$r に取代わることを意図するもの`ではない^em。詳細は、 `§ ~HSTSとの関係＠#relation-to-hsts$ を見よ。 ◎ Note: The mechanism defined here does not intend to supplant Strict Transport Security [RFC6797]. See § 7.2 Relation to HSTS for details.

1.2. 各種~例

1.2.1. 非~naviによる昇格

Megacorp 社は、 `http://example.com/^s から `https://example.com^s へ移行したいと望んでいるとする。彼らは、所有する資源が~HTTPS越しに可用になるよう，自身の~serverを設定しておいた上で、第三者-主体~widgetも~secureに可用にするため，~partnerたちとも協働する。 ◎ Megacorp, Inc. wishes to migrate http://example.com/ to https://example.com. They set up their servers to make their own resources available over HTTPS, and work with partners in order to make third-party widgets available securely as well.

しかしながら，彼らはすぐに、それらの内容の大部分が，古い内容~管理~systemに縛られた~database内に閉じ込められていて，~secureでない資源を指す直書きの~link（例：画像その他の内容への http:// ~URL ）を包含することを悟った。あいにく、それを更新するには相当な作業~量を~~要する。 ◎ They quickly realize, however, that the majority of their content is locked up in a database tied to an old content management system, and it contains hardcoded links to insecure resources (e.g., http:// URLs to images and other content). Unfortunately, it’s a substantial amount of work to update it.

当座しのぎとして、 Megacorp 社は，自身の~serverから発せられるどの~HTML応答の中にも次の~headerを注入することにした： ◎ As a stopgap measure, Megacorp injects the following header field into every HTML response that goes out from their servers:

`Content-Security-Policy$h: `upgrade-insecure-requests$dir

これは、社の~pageからの資源~要請のうち~secureでないものは，すべて~secureな変種に自動的に`昇格-$させ、 ~UAが，次の~HTML~codeを： ◎ This automatically upgrades all insecure resource requests from their pages to secure variants, allowing a user agent to treat the following HTML code:

<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">

次が送達されたかのように扱えるようにする： ◎ as though it had been delivered as:

<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">

~URLは、要請が為される前に書直されることになる — それは、 ~secureでない要請が~networkを叩くことはないことを意味する。すべての資源~要請は，労せず透過的に`昇格-$されることになるので、利用者にとってはより安全になり， Megacorp 社の管理者にとっては喜ばしい結果になる。 ◎ The URL will be rewritten before the request is made, meaning that no insecure requests will hit the network. Users will be safer, and Megacorp’s administrators will be happier, as all resource requests will be transparently upgraded with no effort on their part.

1.2.2. ~naviによる昇格

Megacorp 社は、まだ `Strict-Transport-Security$h ~header `RFC6797$r を送達する準備はできていないが、アリなときは，利用者を~secureな~page上に保つよう求めているとする。幸いなことに，これは `upgrade-insecure-requests$dir にタダでついてくる。すなわち、彼らはすでに，次の~headerを伴わせて~pageを送達している： ◎ Megacorp, Inc. isn’t quite ready to deliver Strict Transport Security headers [RFC6797], but does want to keep users on secure pages when possible. Happily, this comes for free with upgrade-insecure-requests. That is, they’re already delivering pages with the following header:

`Content-Security-Policy$h: `upgrade-insecure-requests$dir

これは、 ~UAが次の~HTML~codeを： ◎ This allows user agents to treat the following HTML code:

<a href="http://example.com/">Home</a>

次が送達されたかのように扱えるようにする： ◎ as though it had been delivered as:

<a href="https://example.com/">Home</a>

一方で、第三者-主体~siteへの~linkは，`昇格-$されないことになる。すなわち、次の~HTML~code： ◎ Links to third-party sites will not be upgraded. That is, the following HTML code:

<a href="http://not-example.com/">Home</a>

は，`昇格-$されない。 ◎ won’t be upgraded.

1.2.3. 失敗した昇格

Tinycorp 社は `upgrade-insecure-requests$dir を可能化したが、時期尚早であった — 実際にはまだ `http://cdn.example.com/^s 上で~HTTPSを~supportしていなかったので。次の~codeが与えられたとする： ◎ Tinycorp, Inc. enabled upgrade-insecure-requests a bit earlier than they should have, as they don’t actually support HTTPS on http://cdn.example.com/. Given the following code:

<img src="http://cdn.example.com/image.png">

~UAは、 `§ 非~naviによる昇格＠#example-nonnavigational$ にて述べたとおり，~URLを `https://cdn.example.com/image.png^s に書直して要請を`昇格-$することになる。 ~serverは~secureな要請に応答しないので、その結果は~network~errorになる。 ◎ User agents will upgrade requests, as described in § 1.2.1 Non-navigational Upgrades, rewriting the URL as https://cdn.example.com/image.png. As the server doesn’t respond to secure requests, this results in a network error.

この局面に際しては、 ~fallbackは無い。 ~UAは［意図的に，そのように要請を為すものとされた］と受け取って動作するので、要請は失敗する。 ◎ There is no fallback in this scenario: the user agent acts just as though the request had been intentionally made, and the request fails.

1.3. 各種~推奨

作者【~server運用者】には、［ `昇格の仕組み$を~supportする~UAが，アリな限り~secureになる］よう確保したいと望むなら，次を行うことを推奨する： ◎ We recommend that authors who wish to ensure that user agents which support upgrade-insecure-requests are as secure as possible do the following:

~secureでないかつ`安全に昇格-可能$な要請に対しては、［状態s~code `307^st, `Location$h ~header ］を伴う応答することにより，~HTTPから~HTTPSへ~redirectする。 ◎ Redirect insecure, safely upgradable requests from HTTP to HTTPS by responding with a Location header and a 307 status code.
~Nginxにおいては、この種の~redirectionは，次の様になるであろう： ◎ In Nginx, this kind of redirection might look like this:
```
server {
  if ($http_upgrade_insecure_requests = "1") {
    add_header Vary Upgrade-Insecure-Requests;
    return 307 https://$host$request_uri;
  }
}
```
無論これは，ごく単純~化されており、 ~~実際の環境設定はずっと複階的になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.
`信用に価し得る~URL$に`安全に昇格-可能$な要請に対しては、要請されている資源に必要yなら， `upgrade-insecure-requests$dir 指令を伴わせて応答する。 ◎ Respond to potentially trustworthy URL safely upgradable requests with a upgrade-insecure-requests directive if necessary for the resource being requested.
~Nginxにてこの指令を追加するときは、次の様になるであろう: ◎ In Nginx, adding this directive might look like this:
```
server {
  ...

  add_header `Content-Security-Policy$h `upgrade-insecure-requests$dir;

  ...
}
```
無論これは，ごく単純~化されており、 ~~実際の環境設定はずっと複階的になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.
生成元が`~HSTS安全$である場合、 ~SSL-stripping中間者~攻撃に抗して保護するため，［ `preload^dir 指令を伴う `Strict-Transport-Security$h ~headerを送信して， `混在~内容^cite の`厳密~mode$を可能化する］ことにより［ ~secureでない内容は，決して読込まれない］ことを確保する。 ◎ If the origin is HSTS-safe, then protect against SSL-stripping man-in-the-middle attacks by sending a Strict-Transport-Security header with the preload directive, and ensure that insecure content is never loaded by enabling Mixed Content’s strict mode.
~Nginxにてこの~headerを追加するときは、次の様になるであろう（ `preload^dir 【！preloaded】指令の利用は、この生成元の~HSTS状態を~~通達し，~UAの HSTS Preload Lists に安全に取込まれることに注意）： ◎ In Nginx, adding this header might look like this (note the use of the preloaded directive, which signifies that this origin’s HSTS state can be safely imported into user agents' HSTS preload lists):
```
server {
  ...
  
  add_header `Strict-Transport-Security$h "max-age=10886400; preload"
  add_header `Content-Security-Policy$h `block-all-mixed-content$dir;

  ...
}
```
無論これは，ごく単純~化されており、 ~~実際の環境設定はずっと複階的になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.
加えて、 ~UA~vendorたちと協働する — 当の生成元を HSTS Preload Lists に追加することを通して（例えば、当の生成元を `hstspreload.appspot.com＠https://hstspreload.appspot.com/$ まで届出ることにより）。 ◎ Additionally, work with user agent vendors to add the origin to HSTS Preload Lists (for example, by submitting the origin to hstspreload.appspot.com).
生成元が`条件付きで~HSTS安全$の場合、 `安全に昇格-可能$な要請のみに呼応して~HSTSを~opt-intoする。 ◎ If the origin is conditionally HSTS-safe, then opt-into HSTS only in response to safely upgradable requests.
~Nginxにてこの~headerを条件付きで追加するときは、次の様になるであろう（ note the use of `map^c, as setting headers inside `if^c without returning immediately is, well, iffy 【~Nginxには不詳なので，原文のままにしておく】）： ◎ In Nginx, adding this header conditionally might look like this (note the use of map, as setting headers inside if without returning immediately is, well, iffy):
```
server {
  ...

  map $http_https $sts {
    "1" "max-age=10886400"
  }
  
  add_header `Strict-Transport-Security$h $sts;

  ...
}
```
無論これは，ごく単純~化されており、 ~~実際の環境設定はずっと複階的になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.

2. 主要な概念と各種用語

`昇格の仕組み@

この文書に述べる，（~URLを透過的に~secureな~URLに`昇格-$しても）~pageが非互換化されないようにするための `upgrade-insecure-requests$dir の仕組みを指す。（~page／資源／~site が） “昇格の仕組みを要する” とは、［ ~UAにおいて`昇格の仕組み$が~supportされている］ことを要することを意味する。

【この用語は、本文の記述を簡潔に, かつ一貫させるために，この訳に導入している。原文では、 “この文書に述べる〜” に記した様な長い修飾がいちいち付いていて，読みにくいので — おそらく、 ~HTTP `Upgrade^h ~headerなどによる，他の “昇格の仕組み” と区別するためと思われるが、 “昇格” が他の意味を指す箇所は，この仕様には現れない。】

要請を `昇格-@ する ◎ upgrade

~URLの`~scheme$urlが［ `http^l ／ `ws^l ］から［ `https^l ／ `wss^l ］へ書直された`要請$は、 昇格されたという。 ◎ A request is said to be upgraded if it is rewritten to contain a URL with a scheme of https or wss.

`安全に昇格-可能@ な要請 ◎ safely upgradable requests

`要請$が安全に昇格-可能であるとは、 ~OR↓ が満たされることをいう：

返される`資源~表現$は、 `昇格の仕組み$を要さない
`要請$の`~header~list$rqは、値 `1^v をとる `Upgrade-Insecure-Requests$h ~headerを包含している

◎ A request is said to be safely upgradable if the resource representation which will be returned does not require the upgrade-insecure-requests mechanism described in this document to avoid breakage, or if the request's header list contains an Upgrade-Insecure-Requests header field with a value of 1.

`~HSTS安全@ な生成元 ◎ HSTS-safe origin

`生成元$が~HSTS安全であるとは、 ~AND↓ が満たされることをいう：

それが返すどの`資源~表現$も`昇格の仕組み$を要さない
それが返すどの`資源~表現$も~HTTPS越しに~serveされる

◎ An origin is said to be HSTS-safe if no resource representations it returns requires the the upgrade-insecure-requests mechanism described in this document to avoid breakage, and if all resource representations it returns can be served over HTTPS.

`~HSTS安全$な生成元は、すべての~UAに対し `Strict-Transport-Security$h を安全に~opt-intoできる — `昇格の仕組み$を~supportしない~UAに対しても，~pageが非互換化される~riskなしに。 ◎ HSTS-safe origins can safely opt-into Strict-Transport-Security for all user agents, without risking broken pages for user agents which do not support upgrade-insecure-requests.

`条件付きで~HSTS安全@ な生成元 ◎ conditionally HSTS-safe origin

`生成元$が条件付きで~HSTS安全であるとは、 ~AND↓ が満たされることをいう：

それが返すある`資源~表現$は`昇格の仕組み$を要する
それが返すどの`資源~表現$も~HTTPS越しに~serveされる

◎ An origin is said to be conditionally HSTS-safe if one or more resource representations it returns requires the upgrade-insecure-requests mechanism described in this document to avoid breakage, and if all resource representations it returns can be served over HTTPS.

`条件付きで~HSTS安全$な生成元は、 `昇格の仕組み$を~supportする~UAに対してのみ， `Strict-Transport-Security$h を安全に~opt-intoできる。 ◎ Conditionally HSTS-safe origins can safely opt-into Strict-Transport-Security only for user agents which support upgrade-insecure-requests.

`事前読込-可能な~HSTS~host@ ◎ preloadable HSTS host

`~host$url %~host は、 `Known HSTS Host Domain Name Matching＠~RFCx/rfc6797#section-8.2$en （ “既知な~HSTS~host~domain名との照合” ）を遂行したとき， ~OR↓ を満たすならば、 事前読込-可能な~HSTS~host とされる：

%~host は、［ `includeSubDomains$dir, `preload^dir の両~指令とも表明しているある`既知な~HSTS~host$ ］に `superdomain match＠~RFCx/rfc6797#section-8.2$en する†
%~host は、［ `preload^dir 指令を表明しているある`既知な~HSTS~host$ ］に `congruent match＠~RFCx/rfc6797#section-8.2$en する††

【† “上位~domain合致” — ~HSTS~hostは %~host のある上位~domainに一致する】【†† “合同~合致” — ~HSTS~hostは %~host に一致する】

◎ A host host is a preloadable HSTS host if, when performing Known HSTS Host Domain Name Matching, host is a superdomain match for a Known HSTS Host which asserts both the includeSubDomains directive and the preload directive, or host is a congruent matchfor a Known HSTS Host which asserts the preload directive.

注記：手短に言えば、これらは， “~UAが、［ `preload^dir 指令を包含していた `Strict-Transport-Security$h ~header ］を，手元に~pinしておいた~hostたち” である。 ◎ Note: This is a long way of saying "any host the user agent has pinned with a Strict-Transport-Security header that contained a preload directive".

§ `upgrade-insecure-requests^dir ~CSP指令に利用される~ABNF（ Augmented Backus-Naur Form ）記法は、 `ABNF$r （ RFC5234 ）にて指定される。 ◎ The Augmented Backus-Naur Form (ABNF) notation used in § 3.1 The upgrade-insecure-requests Content Security Policy directive is specified in RFC5234. [ABNF]

【この訳に特有な表記規約】

◎表記記号

3. ~secureでない資源~要請の昇格-法

作者は、資源~要請の~URLを`信用に価し得る~URL$【！variant】に透過的に`昇格-$するよう， ~UAに指図してよい。これにより、 ~secureでない生成元から移行するときの負な副作用を軽減できる。 ◎ In order to allow authors to mitigate the negative side-effects of migration away from insecure origins, authors may instruct the user agent to transparently upgrade resource requests to potentially trustworthy URL variants of the original request’s URL.

この指図を~supportするため、各［ `環境~設定群~obj$／`閲覧~文脈$ ］は，次に挙げるものを有する： ◎ To support this instruction: ◎ ↓

`~secureでない要請~用の施策@ ◎ Environment settings objects and browsing contexts are given an insecure requests policy＼: ［ `昇格するな@i ／ `昇格せよ@i ］いずれかを値にとる — 他が指定されない限り，`昇格するな$i に設定される。 ◎ which has two potential values Do Not Upgrade and Upgrade. It is set to Do Not Upgrade unless otherwise specified.＼; この施策は、 `~fetch$する間に［非~navi要請や~form提出が`昇格-$されるべきか否か］を決定するために［ `適切になるなら，要請を信用に価し得る~URLに昇格する$ ］ときに検査される。 ◎ This policy is checked in § 4.1 Upgrade request to a potentially trustworthy URL, if appropriate in order to determine whether or not non-navigation requests and form submissions should be upgraded during fetching.
`~secureでない~navi用の昇格~集合@ ◎ Environment settings objects and browsing contexts are given an upgrade insecure navigations set＼: ~naviが昇格するべきとされる，［ ( `~host$url, `~port$url ) が成す~tuple ］たちが成す集合 — 他が指定されない限り，空とする。 ◎ which contains a set of (host, port) tuples to which navigations ought to be upgraded. Its value is the empty set unless otherwise specified.＼; この集合は、［ `~navi要請$が`昇格-$されるべきか否か］を決定するために，［ `適切になるなら，要請を信用に価し得る~URLに昇格する$ ］ときに検査される。 ◎ This set is checked in § 4.1 Upgrade request to a potentially trustworthy URL, if appropriate in order to determine whether or not navigation requests should be upgraded.

3.1. `upgrade-insecure-requests^dir ~CSP指令

~serverは、［ `upgrade-insecure-requests@dir 指令を包含する `Content-Security-Policy$h ~header `CSP$r ］を送信することにより，［特定0の`保護される資源$へ向けた~secureでない要請］を`昇格-$するよう，~UAに指図してもヨイ。この指令は、次の `ABNF$r 文法で定義される： ◎ A server MAY instruct a user agent to upgrade insecure requests for a particular protected resource by sending a Content-Security-Policy header [CSP] that contains a upgrade-insecure-requests directive, defined via the following ABNF grammar:

`directive-name$P
	= "upgrade-insecure-requests"
`directive-value$P
	= ""

`upgrade-insecure-requests^dir 指令を`施行-$するときは： ◎ When enforcing the upgrade-insecure-requests directive:

%設定群 ~LET `保護される資源$の`現任な設定群~obj$ ◎ Let settings be the protected resource’s incumbent settings object.
%設定群の`~secureでない要請~用の施策$ ~SET `昇格せよ$i ◎ Set settings’s insecure requests policy to Upgrade.
%~tuple ~LET `保護される資源$の`~URL$の ( `~host$url, `~port$url ) が成す~tuple ◎ Let tuple be a tuple of the protected resource’s URL's host and port.
%~tuple を %設定群の`~secureでない~navi用の昇格~集合$に挿入する ◎ Insert tuple into settings’s upgrade insecure navigations set.

`監視-$時においては、 `upgrade-insecure-requests^dir 指令の効果はない — すなわち、この指令が `Content-Security-Policy-Report-Only$h ~headerを介して送信されたときは無視される。作者は、 `Content-Security-Policy-Report-Only$h を介して，昇格された資源の元の~URLが~secureでなかったかどうかを決定できる。例えば次のように：

`Content-Security-Policy-Report-Only$h: default-src https:; report-uri /endpoint

追加的な詳細は、 `§ 昇格の報告-法＠#reporting-upgrades$ を見よ。

◎ Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header. Authors can determine whether or not upgraded resources' original URLs were insecure via Content-Security-Policy-Report-Only. For example, Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint. See § 3.4 Reporting Upgrades for additional detail.

3.1.1. “混在~内容” との関係

`upgrade-insecure-requests$dir 指令は、【！at the top of】`~fetch$ ~algo `FETCH$r 【の一部を成す`~main~fetch$】の中で，［ `適切になるなら，要請を信用に価し得る~URLに昇格する$ ］の結果に従って，要請が書直されるようにする。この書直しは、［ `混在~内容^cite `MIX$r ／ `~CSP^cite `CSP$r ］による検査の効果が`生じるより前^emに起こることが重要であることに注意。この順序付けは、次を意味する： ◎ The upgrade-insecure-requests directive results in requests being rewritten at the top of the Fetching algorithm [FETCH], as specified in § 4.1 Upgrade request to a potentially trustworthy URL, if appropriate. It’s important to note that the rewrite happens before either Mixed Content [MIX] or Content Security Policy checks take effect [CSP].

`昇格-$された要請は、混在~内容として`~~扱われなくなる^em。
`upgrade-insecure-requests$dir 指令の効果は， `block-all-mixed-content$dir 指令が当の要請を阻止する機会cを得る前に生じる。前者が設定された場合、後者は実質的に何もしないことになる。

作者には、 `§ 各種~推奨＠#recommendations$ にて要旨されるとおり，この 2 つの指令のうちいずれか一方は設定することが推奨される。

◎ This ordering means that upgraded requests will not be flagged as mixed content. Moreover, it means that upgrade-insecure-requests’s effect takes place before the block-all-mixed-content directive would have a chance to block the request. If the former is set, the latter is effectively a no-op. ◎ We recommend that authors set one directive or the other, as outlined in § 1.3 Recommendations.

3.2. ~clientの昇格-能力についての特能の検出-法

［ ~secureな移行0-越しに，利用者に適度な体験を供する］ために，`昇格の仕組み$を要する~siteは、何らかの仕方で［ ~~個々の`要請$について，それを~HTTPから~HTTPS（あるいはその逆）へ安全に~redirectできるかどうか］を決定する必要がある。更には、 `条件付きで~HSTS安全$な生成元は，【昇格の仕組みを】~supportする~UAに限って `Strict-Transport-Security$h を~opt-intoできる — そうしなければ、 ~siteの利用者にとってよくない結果になりかねない。 ◎ Sites which require the upgrade mechanism laid out in this document in order to provide users with a reasonable experience over secure transit need some way to determine whether or not a particular request can safely be redirected from HTTP to HTTPS (and vice-versa). Moreover, conditionally HSTS-safe origins can only opt-into Strict-Transport-Security for supported user agents, and doing otherwise could have negative consequences for the site’s users.

この裁定は、 ~UA `sniffing^en 【~serverが，~UAが昇格の仕組みを~supportするかどうか~~推測（ `sniff^en ）すること？】に依拠して為すものではない — ~UAは、 `~navi要請$を為すときに `Upgrade-Insecure-Requests$h ~headerを内包することにより，自身の昇格~能力を告知できる。 § `Upgrade-Insecure-Requests^h ~HTTP要請~header を見よ。 ◎ Rather than relying on user-agent sniffing to make this decision, user agents can advertise their upgrade capability when making navigation requests by including an Upgrade-Insecure-Requests header field as described in § 3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field.

3.2.1. `Upgrade-Insecure-Requests^h ~HTTP要請~header

`Upgrade-Insecure-Requests@h ~HTTP要請~headerは、次を表出する通達を~serverへ向けて送信する： ◎ The Upgrade-Insecure-Requests HTTP request header field sends a signal to the server expressing＼

~clientは、暗号化され, かつ認証された応答を選好すること，および ◎ the client’s preference for an encrypted and authenticated response,＼
~clientは、 `upgrade-insecure-requests$dir 指令を成功裡に取扱えるので，その選好をアリな限り円滑に供せる。 ◎ and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.

この選好は、次の `ABNF$r 文法で表現される： ◎ This preference is represented by the following ANBF:

"Upgrade-Insecure-Requests:" *`WSP$P "1" *`WSP$P

注記： `Upgrade-Insecure-Requests^h ~headerは，選好を表出するが、それを既存の `Prefer$h ~headerを介して送信すると，問題になり得る — ~serverからの応答に利用されるそれは、 ~cache~keyの一部を成すことが予期されるので。 `w3c/webappsec 課題 #216＠https://github.com/w3c/webappsec/issues/216$ にて論じられるとおり、 `Vary$h: `Prefer^v は，対象が広過ぎる。 ◎ Note: Though the Upgrade-Insecure-Requests header expresses a preference, sending it via the existing Prefer header is problematic, as we expect the response from the server to use it as part of the cache key. Vary: Prefer is too broad, as discussed in w3/webappsec#216.

~UAの適合性についての詳細は、［ `適切になるなら，要請を信用に価し得る~URLに昇格する$ ］~algoの段 #1 にて述べる。その段は、次のような~UA要件を表現する： ◎ User agent conformance details are described in step #1 of the the § 4.1 Upgrade request to a potentially trustworthy URL, if appropriate algorithm. That step represents the following requirements:

以下における %~URL は、 ~UAが送信する`要請$の`~URL$rq を表すとする。 ◎ ↓
%~URL は~secureでない【`信用に価し得る~URL$でない】場合 ⇒ `要請$に `Upgrade-Insecure-Requests$h ~headerも伴わせるモノトスル。 ◎ User agents MUST send an Upgrade-Insecure-Requests header field along with requests for insecure URLs.

注記： ~serverは、この通達を利用して，`昇格の仕組み$を要する~pageへ向けた ~HTTP要請を，~HTTPSに`昇格-$させれる。 ◎ Note: Servers can use this signal to upgrade HTTP requests to HTTPS for pages that require upgrade-insecure-requests support.
%~URL は`信用に価し得る~URL$である場合、 %~URL の`~host$urlに応じて： ◎ ↓
- `事前読込-可能な~HSTS~host$でないならば ⇒ `要請$に `Upgrade-Insecure-Requests$h ~headerを伴わせるモノトスル。 ◎ User agents MUST send an Upgrade-Insecure-Requests header field along with requests for potentially trustworthy URLs whose URL's host is not a preloadable HSTS host.
  
  注記： ~serverは、この通達が無いことを利用して，`昇格の仕組み$を要する~pageへ向けた ~HTTPS要請を，~HTTPに降格できる。 ◎ Note: Servers can use the absence of this signal to downgrade HTTPS requests to HTTP for pages that require upgrade-insecure-requests support.
- `事前読込-可能な~HSTS~host$であるならば ⇒ 定期的に，`要請$に `Upgrade-Insecure-Requests$h ~headerを伴わせるべきである。 ◎ User agents SHOULD periodically send an Upgrade-Insecure-Requests header field along with requests for potentially trustworthy URLs whose URL's host is a preloadable HSTS host.＼
  
  例えば、［表明された `max-age^dir の失効が 2 〜 3 日後に迫っているとき］や少ない割合の要請に限って， `Upgrade-Insecure-Requests$h ~headerを送信することもできる。 ◎ For example, user agents could send an Upgrade-Insecure-Requests header field only when the asserted max-age is a few days from expiration, or only for a small percentage of requests.
  
  注記： `事前読込-可能な~HSTS~host$は，自身は`~HSTS安全$であると表明-済みなので、降格する通達は必要はない。そのような~hostは，表明された `max-age^dir が失効する前に~HSTS状態sを刷新する必要があり、 `Upgrade-Insecure-Requests$h ~headerは，その~HSTSを刷新させる通達として申し分なく~~働く。 ◎ Note: preloadable HSTS hosts have asserted that they are HSTS-safe, and therefore don’t need a downgrade signal. They will need to refresh HSTS status before the asserted max-age expires, and the Upgrade-Insecure-Requests header field serves as a fine signal that HSTS could be refreshed.

~serverが~HTTP要請の~header内でこの選好に遭遇したときは： ◎ ↓

要請されている資源~用の`信用に価し得る~URL$【！variant】へ，利用者を~redirectするベキである。 ◎ When a server encounters this preference in an HTTP request’s headers, it SHOULD redirect the user to a potentially trustworthy URL variant of the resource being requested.
要請の`~host$urlが［ `~HSTS安全$／ `条件付きで~HSTS安全$ ］ならば、応答~内に `Strict-Transport-Security$h ~header `RFC6797$r を内包するベキである。 ◎ When a server encounters this preference in an HTTPS request’s headers, it SHOULD include a Strict-Transport-Security header in the response if the request’s host is HSTS-safe or conditionally HSTS-safe [RFC6797].

`昇格の仕組み$を~supportする~clientは、 `http://example.com/^s へ次のように要請する： ◎ A client that supports this document’s upgrade mechanism requests http://example.com/ as follows:

GET / HTTP/1.1
Host: example.com
`Upgrade-Insecure-Requests$h: 1

~serverは、選好を構文解析した結果，［利用者の~clientは，昇格-要請にきちんと対処できる］ことに気付いたので、要請に対し［利用者が要請している資源の~secureな~version ］へ~redirectするよう応答する場合： ◎ The server parses the preference, notices that the user’s client can deal well with upgrade requests, and therefore responds to the request by redirecting the user to a secure version of the resource she’s requesting:

HTTP/1.1 307 Moved Temporarily
`Location$h: https://example.com/
`Vary$h: `Upgrade-Insecure-Requests$h

`Vary$h ~header内には `Upgrade-Insecure-Requests$h ~headerが~listされている — さもなければ、 ~redirect応答は，［ `昇格の仕組み$を~supportしない~client ］用の~cacheにより~serveされるようになるかもしれないので。類似な効果は、［ `Cache-Control$h ~headerを介して，この~redirect応答を~cache不能にする］ことでも達成できる： ◎ The Upgrade-Insecure-Requests header field is listed in the Vary header, as the redirect response might otherwise be served by caches to clients that don’t support the upgrade mechanism defined here. A similar effect could be achieved by making this redirect response uncachable via the Cache-Control header:

HTTP/1.1 307 Moved Temporarily
`Location$h: https://example.com/
`Cache-Control$h: `no-store$dir

3.3. 施策の継承

［ `文書$の`現任な設定群~obj$の`~secureでない要請~用の施策$ ~EQ `昇格せよ$i ］の場合、 ~UAは，次の仕方で，すべての`入子な閲覧~文脈$に設定が継承されることを確保するモノトスル： ◎ If a Document's incumbent settings object’s insecure requests policy is set to Upgrade, the user agent MUST ensure that all nested browsing contexts inherit the setting in the following ways:

`入子な閲覧~文脈$ %文脈を作成するときは： ◎ When a nested browsing context context is created:
1. %文書 ~LET %文脈を`埋込んでいる文書$ ◎ ↓
2. ~IF［ %文書【が`属する閲覧~文脈$】の`~secureでない要請~用の施策$ ~EQ `昇格せよ$i ］： ◎ If context’s embedding document’s insecure requests policy is Upgrade, then:
  1. %文脈の`~secureでない要請~用の施策$ ~SET `昇格せよ$i ◎ Set context’s insecure requests policy to Upgrade.
  2. %文書【が`属する閲覧~文脈$】の`~secureでない~navi用の昇格~集合$を成す ~EACH( %値 ) に対し ⇒ %文脈の`~secureでない~navi用の昇格~集合$に %値を追加する ◎ For each value in context’s embedding document’s upgrade insecure navigations set, add value to context’s upgrade insecure navigations set.
`閲覧~文脈$ %文脈内に`新たな文書を作成-$をするときは： ◎ When creating a new Document object document in a browsing context context:
1. ~IF［ %文脈の`~secureでない要請~用の施策$ ~EQ `昇格せよ$i ］： ◎ If context’s insecure requests policy is Upgrade, then:
  1. %設定群 ~LET 作成される文書の`現任な設定群~obj$ ◎ Let settings be document’s incumbent settings object.
  2. %設定群の`~secureでない要請~用の施策$ ~SET `昇格せよ$i ◎ Set settings’ insecure requests policy to Upgrade.
  3. %文脈の`~secureでない~navi用の昇格~集合$を成す ~EACH( %値 ) に対し ⇒ %設定群の`~secureでない~navi用の昇格~集合$に %値を追加する ◎ For each value in context’s upgrade insecure navigations set, add value to settings’s upgrade insecure navigations set.

同様に，~workerの~~始動時には、 ~UAは，次の仕方でそれを作成した文脈から設定が継承されることを確保するモノトスル： ◎ Likewise, when spinning up a worker, the user agent MUST ensure that it inherits the setting from the context that created it in the following ways:

`~worker環境~設定群~objを設定しておく$ ~algoの，現在の段 #4 の後に次の手続きを~~挿入する： ◎ When executing the set up a worker environment settings object algorithm, perform the following steps after the current step #4:
1. ~IF［ `継承した担当の閲覧~文脈^V の`~secureでない要請~用の施策$ ~EQ `昇格せよ$i ］： ◎ If inherited responsible browsing context’s insecure requests policy is Upgrade, then:
  1. %設定群~obj の`~secureでない要請~用の施策$ ~SET `昇格せよ$i ◎ Set settings object’s insecure requests policy to Upgrade.
  2. `継承した担当の閲覧~文脈^V の`~secureでない~navi用の昇格~集合$を成す ~EACH( %値 ) に対し ⇒ %設定群~obj の`~secureでない~navi用の昇格~集合$に %値を追加する ◎ For each value in inherited responsible browsing context’s upgrade insecure navigations set, add value to settings object’s upgrade insecure navigations set.

3.4. 昇格の報告-法

~secureでない要請の昇格-法は、［ `昇格の仕組み$を~supportしない~UAにおいて要請が~secureでないものになるかどうかを，作者が突き止めれる能］には，干渉しないモノトスル。そのため、 `昇格-$は，［ %要請を`監視-$下にある~security施策すべてに対し評価した`後^em ］かつ［ %要請を`施行-$下にある~security施策すべてに対し評価する`前^em ］に遂行するモノトスル。 ◎ Upgrading insecure requests MUST not interfere with an authors' ability to track down requests that would be insecure in a user agent that does not support upgrades. To that end, upgrades MUST be performed after evaluating request against all monitored security policies, but before evaluating request against all enforced policies.

`保護される資源$が，~secureでない画像 `<img src="http://example.com/image.png">^s を包含していて，次の~HTTP~headerを送達するような文脈の中では： ◎ Within the context of a protected resource which contains the insecure image <img src="http://example.com/image.png">, and delivers the following HTTP headers:

`Content-Security-Policy$h: `upgrade-insecure-requests$dir; `default-src$dir https:
`Content-Security-Policy-Report-Only$h: `default-src$dir https:; `report-uri$dir /endpoint

~UAは、 `要請$ %要請を次のように取扱うことになる： ◎ The user agent will fire off a request request that:

%要請が`監視-$下にある施策に違反するならば、それに従って `/endpoint^s へ`違反~報告$xを送達する。 ◎ Violates the policy being monitored, thereby delivering a violation report to /endpoint.
%要請を `http://example.com/image.png^s から `https://example.com/image.png^s へ昇格する。 ◎ Is upgraded from http://example.com/image.png to https://example.com/image.png.
%要請は、 `施行-$下にある施策には違反しない。 ◎ Does not violate the policy being enforced.

注記： `CSP$r が`FETCH$r の用語を通して書直されたなら、これは，有意に明確化されることになる。 ◎ Note: This will be significantly clarified once [CSP] is rewritten in terms of [FETCH].

4. 各種処理~algo

4.1. 適切になるなら %要請を`信用に価し得る~URL$に昇格する

この~algoは、所与の`要請$ %要請に対し，［ %要請が出自にしている`~client$rq ］が昇格を~opt-inしていたならば、 %要請の`~URL$rqを書直す。それはまた、 ~secureでない`~navi要請$に対し，［ ~serverによる~clientの昇格~特能を検出する能を改善する］ために， `Upgrade-Insecure-Requests$h ~headerを注入する。 ◎ Given a request request, this algorithm will rewrite its URL if the client from which the request originates has opted-in to upgrades. It will also inject an Upgrade-Insecure-Requests header field header for insecure navigation requests in order to improve a server’s ability to feature-detect a client’s upgrade capabilities.

~form提出は例外として、非同一-生成元`~navi要請$は`昇格-$されない。 ~form提出は、平文text提出を介して~dataが漏洩される~riskを軽減するため，昇格されることになる。 ◎ We will not upgrade cross-origin navigation requests, with the exception of form submissions. Form submissions will be upgraded to mitigate the risk of data leakage via plaintext submissions.

注記：この~algoは、 `~main~fetch$~algoの冒頭で~callされる。 ◎ Note: This algorithm is called at the top of the Main Fetch algorithm.

%~URL ~LET %要請の`~URL$rq ◎ ↓
~IF［ %要請は`~navi要請$である］~AND［［ %~URL は`信用に価し得る~URL$でない］~OR［ %~URL の`~host$urlは`事前読込-可能な~HSTS~host$`でない^em ］］ ⇒ %要請の`~header~list$rqに`~headerを付加する$( ( `Upgrade-Insecure-Requests^h, `1^v ) ) ◎ If request is a navigation request, append a header named Upgrade-Insecure-Requests with a value of 1 to request’s header list if any of the following criteria are met: • request’s URL is not a potentially trustworthy URL • request’s URL's host is not a preloadable HSTS host

注記： ~UAは、他の要請に対しても `Upgrade-Insecure-Requests$h ~headerを付加することを選べる — § `Upgrade-Insecure-Requests^h ~HTTP要請~header にて論じたとおり。 ◎ Note: User agents can choose to append the Upgrade-Insecure-Requests header field for other requests, as discussed in § 3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field.
~IF［ ~AND↓ ］… ◎ ↓
- %要請は`~navi要請$である ◎ If request is a navigation request, then:
- %要請は~form提出でない ◎ If request is a form submission, skip the remaining substeps, and continue upgrading request.
- %要請の`~client$rqの`~target閲覧~文脈$enVは`入子な閲覧~文脈$でない ◎ If request’s client's target browsing context is a nested browsing context, skip the remaining substeps and continue upgrading request.
- %~URL の ( `~host$url, `~port$url ) が成す~tuple ~NIN %要請の`~client$rqの`~secureでない~navi用の昇格~集合$ ◎ Let tuple be a tuple of request’s URL's host and port. ◎ If tuple is contained in client's upgrade insecure navigations set, then skip the remaining substeps, and continue upgrading request.
…ならば ⇒ ~RET ◎ Return without further modifying request.

注記： ~top-level`~navi要請$が`昇格-$されるのは、 `§ 各種~例＠#examples$ にて述べたとおり，［特定0の`保護される資源$に対し，挙動を明示的に~opt-intoした~host ］に限られる。第三者-主体~資源への~top-level~naviに対し昇格を遂行することは、非互換化の可能性を有意に高めるので，当面は避けることにしている。入子な~navi（例えば `iframe$e を介するもの）に対しては，その埋込元の~security状態sに影響するので、必要yなら，その昇格を確保する。 ◎ Note: We only upgrade top-level navigation requests for hosts that have explicitly opted-into the behavior for a particular protected resource, as described in § 1.2 Examples. Performing upgrades for top-level navigations to third-party resources brings a significantly higher potential for breakage, so we’re avoiding it for the moment. Nested navigations (via iframe, for example) affect the security status of their embedder, so we ensure that they are upgraded if necessary.
~IF［［ %要請の`~client$rqに対する`~secureでない要請は昇格されるべきか？$ ］の結果 ~EQ `昇格するな$i ］ ⇒ ~RET ◎ Let upgrade state be the result of executing § 4.2 Should insecure requests be upgraded for client? upon request’s client. ◎ If upgrade state is Do Not Upgrade, return without modifying request.
~IF［ %~URL の`~scheme$url ~EQ `http^l ］ ⇒ %~URL の`~scheme$url ~SET `https^l ◎ If request’s URL's scheme is "http", set request’s URL's scheme to "https", and return.

注記： `FETCH$r の再帰的な資質に因り、この~algoは，初期~要請のみならず ~redirectに対しても，~secureでない要請を`昇格-$することになる。 ◎ Note: Due to [FETCH]'s recursive nature, this algorithm will upgrade insecurely-redirected requests as well as insecure initial requests.

4.2. %~client に対する~secureでない要請は昇格されるべきか？

この~algoは、所与の［ `要請$の`~client$rq ］ %~client （`環境~設定群~obj$）に結付けられる~secureでない要請が昇格されるべきならば `昇格せよ$i【！Enforced Upgrade】／ ~ELSE_ `昇格するな$i ］を返す。 ~~要約すると、これは %~client を検査して，［ %~client, または %~client の`閲覧~文脈$ ］に設定された適切な`~secureでない要請~用の施策$を返す： ◎ Given an request's client client (an environment settings object), this algorithm returns Enforced Upgrade if insecure requests associated with that client should be upgraded, or Do Not Upgrade otherwise. In short, this will check the client and return the appropriate insecure requests policy set on it or its browsing context.

~IF［ %~client には `responsible^en 文書†がある］ ⇒ ~RET その`~secureでない要請~用の施策$ ◎ If client has a responsible document, return the value of its insecure requests policy.
注記：これは，次のいずれかに該当する［ `Document$I ／ `Worker$I ］を~catchする：
- `upgrade-insecure-requests$dir 指令により施策が直に設定されているもの
- `埋込んでいる文書$から施策を継承しているもの
◎ Note: This catches Documents or Workers whose policy is set directly by the upgrade-insecure-requests directive, or which have inherited the policy from an embedding document.
~IF［ %~client には `responsible^en 閲覧~文脈†がある］ ⇒ ~RET その`~secureでない要請~用の施策$ ◎ If client has a responsible browsing context, return the value of its insecure requests policy.

注記：これは、 `detach^en された`~client$rqから誘発された要請を~catchする。 `§ 施策の継承＠#nesting$ にて定義される継承~構造が与えられた下で、これが本当に必要yであるかどうかは確かでない。【？】 ◎ Note: This catches requests triggered from detached clients. Not sure this is necessary, really, given the inheritance structure defined in § 3.3 Policy Inheritance.
~RET `昇格するな$i ◎ Return Do Not Upgrade.

【† これらの用語 “（ `responsible^en 〜）” は、 `HTML$r に定義されていたが，今や廃された（ ~HTML `課題 #5422＠~HTMLissue/5422$, `課題 #4335＠~HTMLissue/4335$） — この~algoは、更新される必要がある（ `課題 #27＠https://github.com/w3c/webappsec-upgrade-insecure-requests/issues/27$ ）。】

5. ~securityの考慮点

5.1. ~HSTSとの相互作用

`upgrade-insecure-requests$dir 指令は、 `Strict-Transport-Security$h ~HTTP応答~header `RFC6797$r を置換するものではない。自身の~siteを~secureな~transport越しに~serveしている作者は、利用者が悪意的な［能動的／受動的］~network攻撃者による［ ~SSL-stripping攻撃や, 監視］の~subjectにされないことを確保するため，［適切な `max-age^dir を伴う~headerを送信する］ベキである。 ◎ The upgrade-insecure-requests directive does not replace the Strict-Transport-Security HTTP response header [RFC6797]. Authors who serve their site over secure transport SHOULD send that header with an appropriate max-age in order to ensure that users are not subject to SSL stripping attacks by maliciously active network attackers, or monitoring by maliciously passive network attackers.

5.2. ~CSP違反~報告

~UAは、昇格された資源に対し違反~報告を送信するときは，当の要請を誘発した［ `Document$I ／ `Worker$I ］を~targetにするモノトスル — `upgrade-insecure-requests$dir 指令が設定された［ `Document$I ／ `Worker$I ］ではなく。 `§ 施策の継承＠#nesting$ に因り，後者は前者とは非同一-生成元な先祖かもしれず、その場合，違反~報告を［報告-先端点の集合］へ送信すると，期待されない仕方で~dataが漏洩され得るので。 ◎ When sending a violation report for an upgraded resource, user agents MUST target the Document or Worker that triggered the request, rather than the Document or Worker on which the upgrade-insecure-requests directive was set. Due to § 3.3 Policy Inheritance, the latter might be a cross-origin ancestor of the former, and sending violation reports to that set of reporting endpoints could leak data in unexpected ways.

同じ理由から、 `SecurityPolicyViolationEvent$I は，当の要請を誘発した`文書$以外は~targetにしないモノトスル。 ◎ Likewise, the SecurityPolicyViolationEvent MUST NOT target any Document other than the one which triggered the request, for the same reasons.

6. 処理能~上の考慮点

`昇格の仕組み$は、 `事前読込-可能な~HSTS~host$でない~hostへ向けた外方へのどの`~navi要請$にも `Upgrade-Insecure-Requests: 1^s【！\r\nは改行】を追加する（ [email protected], および `w3c/webappsec 課題 #216＠https://github.com/w3c/webappsec/issues/216$ にて長く論じられたとおり）。この~headerの利点と意図は、 § `Upgrade-Insecure-Requests^h ~HTTP要請~header にて~~述べる — ~platformの恒久的な設備にはならないよう，しかるべき手続き（`事前読込-可能な~HSTS~host$を築き上げること）はとられているが、この~headerが消え失せる日が来るまでには，長い長い年月を~~要するであろう。 ◎ The upgrade mechanism specified here adds Upgrade-Insecure-Requests: 1\r\n to every outgoing navigation request to non-preloadable HSTS hosts (as discussed at length on public-webappsec@, and w3c/webappsec#216). The advantages and intent of the header are laid out in § 3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field, and though we’ve taken some steps to ensure that it won’t be a permanent fixture of the platform (by carving out preloadable HSTS hosts), it’s going to be a long, long time before the header vanishes.

~UAには、追加的な築き上げを見出して，それを実装することが奨励される。 ◎ User agents are encouraged to find additional carveouts, and implement them.

7. 著作~上の考慮点

7.1. 旧来の~client

混在~内容の阻止-法 `MIX$r は~supportするが`昇格の仕組み$は~supportしない，旧来の~clientは、 ~secureでない~URLを包含している~page上で，最適と言えない体験を~~供し続けることになる。作者は、それらに`違反~報告を送信-$させ，収集された情報を利用して、利用者にとって最も問題になり得る資源はどれかを見定め，最もよく要請されると見込まれる旧来の内容~内の~URLを優先して修正するベキである。 ◎ Legacy clients which do support mixed content blocking [MIX], but do not support the upgrade-insecure-requests directive will continue to have a suboptimal experience on pages containing insecure URLs. Authors SHOULD ensure that they collect violation reports in order to determine which resources are most problematic for their users, and SHOULD use that information to prioritize fixes for URLs in legacy content that users will most likely request.

7.2. ~HSTSとの関係

`昇格の仕組み$が対処するのは、特定の`保護される資源$用の~security施策に限られる。それは、 `Strict-Transport-Security^h ~HTTP応答~header `RFC6797$r を［非推奨にする／置換する／何らかの仕方で抑制する］ものではない。作者は、［利用者が，~SSL-stripping降格-攻撃の~subjectにされないことを確保する］ため，その~headerを利用し続けれるし、また，し続けるべきである — `upgrade-insecure-requests$dir 指令は、［利用者が，第三者-主体~siteの~linkを介して作者~siteを訪問すること］による~top-level~naviに対しては，~HTTPSへの昇格を確保しないので。 ◎ The mechanism specified here deals only with the security policy for a specific protected resource. It does not deprecate, replace, or in any way reduce the value of the Strict-Transport-Security HTTP response header [RFC6797]. Authors can and should continue to use that header to ensure that their users are not subject to SSL stripping downgrade attacks, as the upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation.

同様に、 `Strict-Transport-Security^h ~headerが，暗黙に `upgrade-insecure-requests$dir を作動化するよう挙動することはない。それは、［ある生成元から要請される資源が~networkを非~secureに叩くことは，決してない］ことのみを確保する。 ◎ Likewise, the Strict-Transport-Security header does not imply the behavior that upgrade-insecure-requests activates. It only ensures that resources requested from an origin will never hit the network insecurely.

これらの概念は、意図的に別個に保たれている — 作者は、どちらの挙動も作動化することを選べるが，双方を一緒に束ねるよう強いられるべきでない。 ◎ We are intentionally keeping these concepts distinct, as authors may choose to activate one or the other behavior, but ought not be forced to bind them together.

8. ~IANA考慮点

8.1. `Upgrade-Insecure-Requests^h ~header

恒久的~message~header~registry `RFC3864$r 【`~HTTP~field名~registry＠~IANA-a/http-fields/http-fields.xhtml$cite 】は、次の登録で更新されるべきである： ◎ The permanent message header field registry should be updated with the following registration: [RFC3864]

~header~field名 ⇒ `Upgrade-Insecure-Requests^h ◎ Header field name • Upgrade-Insecure-Requests
適用-可能な~protocol ⇒ http ◎ Applicable protocol • http
位置付け ⇒ 標準 ◎ Status • standard
著作者／変更~制御者 ⇒ ~W3C ◎ Author/Change controller • W3C
仕様~文書 ⇒ この仕様（ § `Upgrade-Insecure-Requests^h ~HTTP要請~header を見よ） ◎ Specification document • This specification (See § 3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field)

8.2. `upgrade-insecure-requests^dir 指令

~CSP指令~registry `RFC7762$r は、次の登録で更新されるべきである： ◎ The Content Security Policy Directive registry should be updated with the following registration: [RFC7762]

指令~名 ⇒ `upgrade-insecure-requests$dir ◎ Directive name • Upgrade-Insecure-Requests
参照先 ⇒ この文書（ § `upgrade-insecure-requests^dir ~CSP指令を見よ） ◎ Reference • This specification (See § 3.1 The upgrade-insecure-requests Content Security Policy directive)

謝辞

この文書の初期~草案を健全に仕立てた `Anne van Kesteren^en 氏に。問題~空間を明確化して，影響iを指摘された `Peter Eckersley^en, `Daniel Kahn Gillmor^en 両氏に。 ◎ Anne van Kesteren helped ensure that the initial draft of this document was sane. Peter Eckersley and Daniel Kahn Gillmor clarified the problem space, and helped point out the impact.

◎要約

この文書は、次を作者に許容するための仕組みを定義する ⇒ ~secureでない資源への要請を~fetchする前に~secureな~transportへ`昇格-$するよう，~UAに指図する ◎ This document defines a mechanism which allows authors to instruct a user agent to upgrade insecure resource requests to secure transport before fetching them.