HTML5.2の見出し毎の内容を雑にまとめる、2.6. Fetching resources (リソースの取得)

2. Common infrastructure (共通基盤) の中の 2.6. Fetching resources (リソースの取得) について

もし、HTML5をWeb Applicationの為でなく、単なる文書 (form要素やJavaScriptによる従来のXMLHttpRequestのような処理、あるいはCookieなどを一切使わない文書) を書くために勉強するなら、恐らく「こういう章が存在する」以上のことを覚えておく必要はない

ただし、そのような単なる文書であっても真にスタンダロンな文書でなければ、例えばimg要素のようなリソースの埋め込みや、link要素で指定されたスタイルシートの取得などもUAはfetchで定められた仕様に従って動いており、この章の内容は無関係ではない

また、もし、HTML5を (User Agentを実装する為でなく) Web Applicationを作成するために勉強するなら、恐らくこの章で定義されている用語や概念は知っておくべきであろう

ただし、そのような Web Application開発者であっても、例えばFetch 概説 - Web API インターフェイス | MDNなどで十分足りる場合が多いであろう

Fetchを全く知らない場合、予備知識なくこの章を読むより、先にLiving StandardのFatch Standardを読んだ方が理解が早いと思われる (非公式版ではあるがFetch Standard (日本語訳)も存在する)

更に併せて読んでおくと良いかもしれない文書を以下に列挙する (なお、筆者は読めていない)


なお、内容についてはあくまで初学者の覚書ですので、正式な仕様はW3CのHTML5.2を確認してください

また、勉強のため、各仕様の邦訳文書、解説文書を読まずに自分で翻訳して覚書を書き終わってから答え合わせとして邦訳文書を参照するようにしています

このため、多くの訳語が一般的な訳と異なっていますのでご注意ください


2.6. Fetching resources (リソースの取得)
2.6.1. Terminology (用語)

ユーザーエージェントは様々な転送プロトコルを実装しているが、この仕様ではもっぱらHTTPに関する動きを定義する

HTTP取得メソッド (HTTP GET method) はプロトコルのデフォルトの検索動作 (例えばFTPのRETR) と同じであり、HTTP用語において安全かつ等冪 (複数回の実行を行っても結果が同じ演算) である

FTPのRETRとは、FTPのリモートファイルをダウンロード(Retrieve)するコマンド、RFC 959参照

HTTP応答コード (HTTP response codes)は他のプロトコルの持つ同様の基本的な意味のステータスと同等である。

例えば "ファイルが見つからない" エラーは 404 コードと同様で、サーバーエラーは500番台のエラーと同様など、と言う事です。

HTTPヘッダー (HTTP heade) 他のプロトコルの分野と基本に同じ意味を持っている

例えばHTTP認証ヘッダー (HTTP authentication headers) は、FTPプロトコルの認証と同じである

参照元ソース (referrer source) はDocumentまたはURLである

ほか、潜在的CORS要求の作成 (create a potential-CORS request) についての記述がある (が、自分は輪をかけて理解できていない)

2.6.2. Processing model (処理モデル)

ユーザーエージェントが基点からURLやリソースを取得する場合の処理

iframe内の場合や、data:URLabout:blankなどの場合の処理が記述されており、更にCookie更新についてフラグ処理、リダイレクトの場合 (HTTPのステータス301/302/303/307の場合)、などユーザーエージェントが実装すべき処理について記述されている


ユーザーエージェントの実装者やWebApplication製作者は把握すべき内容だと思われるが、単にHTMLで文章をマーク付けしたいだけの自分には荷が重くフレーズレベルで単語を眺め、内容は把握していない

2.6.3. Encrypted HTTP and related security concerns (暗号化HTTPとそれに関するセキュリティ上の懸念)

この仕様でHTTPを参照する場合、HTTPsプロトコルで表現されるHTTP-over-TLSにも適用される

ユーザーエージェントは証明書にエラーがあった場合ユーザーに報告し、併せてリソースのダウンロードを拒否するか、又は暗号化なしの時と同様の挙動にしなければならない

ユーザーエージェントはユーザーが以前訪問したサイトに再び訪問した時に暗号化が使用されていなければ、訪問する度に潜在的な問題があることを警告しなければならない

そうしなければユーザーは中間者攻撃に気付くことが出来ない

ほか、デジタル証明書が自己署名、期限切れ、あるいは以前CA署名付きのデジタル証明書だったサイトが自己署名のデジタル証明書に切り替えた場合のユーザーエージェントの振る舞いについて

2.6.4. Determining the type of a resource (リソースタイプの決定)

コンテンツ型メタ情報 (Content-Type metadata) はMIMEスニッフィング仕様 (MIME Sniffing Standard) に従って取得しされ、解釈されなければならない

計算されたリソースの型 (computed type of a resource) 関連した連続する8bitの計算されたメディアタイプを見つけるためのMIME Sniffing Standardで与えられた一貫した方法に基づかねばならない (7. Determining the computed MIME type of a resource - MIME Sniffing Standard 参照)

画像をスニッフィングするための規則 (rules for sniffing images specifically) とリソースがテキストかバイナリィかを区別するための規則 (rules for distinguishing if a resource is text or binary) はMIMEスニッフィング仕様でも定義されており、両方のルールセットはMIMEタイプを返却する

MIMEスニッフィング仕様を厳密に守らない場合、セキュリティ上の問題が生じる可能性がある

2.6.5. Extracting character encodings from <meta> elements (meta要素による文字エンコーディングの抽出)

文字列sを与えられた場合のmeta要素からの文字エンコーディングを抽出するアルゴリズムについて

このアルゴリズムは文字エンコーディングを返却するか、何も返却しない

HTTPの仕様とは異なることに注意すること

2.6.6. CORS settings attributes (CORS設定属性)

CORS設定属性は列挙型の属性となる

CORSモードで資格がsame-originとなる匿名 (Anonymous)または空文字列と、CORSモードで資格がincludeとなる資格情報を使用する (Use Credentials) と、属性が省略された場合のNo CORSモードが存在する

詳細は仕様参照

2.6.7. Referrer policy attributes (リファラーポリシィ方針属性)

リファラーポリシィ属性は、列挙型の属性である

空文字列を含め、リファラーポリシィはこの属性へのキィワードであり、同じ名前の状態にマッピングされる

属性の無効な値のデフォルト値と属性がない場合のデフォルト値は空文字列の状態となる

これらの値による処理への影響の詳細は、この仕様、Fetch Standard仕様、Referrer Policy仕様に定められている


幾つかの信号がFetchの処理モデルに寄与でき、リファラーポリシィ属性はその一つである

一般にこれらの信号が処理される順序は以下のとおりである

  1. リファラーのない (noreferrer) リンクタイプ
  2. リファラーポリシー属性の値
  3. name属性がreferrerに設定されたmeta要素
  4. HTTPヘッダーのリファラーポリシィ