recursal/MDN huggingface dataset:
CSS: カスケーディングスタイルシート
====================

**カスケーディングスタイルシート** (Cascading Style Sheets、**CSS**) はスタイルシート言語であり、HTML や XML (方言である SVG、MathML、XHTML などを含む) で記述された文書の体裁や見栄えを表現するために用いられます。 CSS は、要素が画面上で (あるいは紙や音声といった別のメディア上で) どのように表現されるのかを定義します。

CSS は**オープンウェブ**の核となる言語に含まれており、W3C 標準仕様によってウェブブラウザー間で標準化されています。以前は CSS 仕様書の様々な部分が同時に開発されており、最新勧告の版数付けができていました。皆さんも CSS1、CSS2.1、また CSS3 についても聞いたことがあるでしょう。CSS3 や CSS4 にはなりません。すべてバージョン番号のない CSS になりました。

CSS 2.1 以降、仕様の範囲が大幅に拡大し、CSS モジュールごとに進捗状況が大きく異なるようになったため、モジュールごとに勧告を開発して公開することがより効果的になりました。W3C では、CSS 仕様のバージョン管理の代わりに、最新の CSS 仕様の安定した状態のスナップショットと独立したモジュールの進捗を定期的に取得するようになりました。CSS のモジュールは、CSS Color Module Level 5 のように、バージョン番号またはレベルを持つようになりました。

主なリソース
------

CSS 入門

ウェブ開発が初めての人は、CSS の基本の記事を読んで、CSS とは何か、どのように使用するかを学習しましょう。

CSS チュートリアル

CSS 学習領域は、初心者から中級者になるための、すべての基本事項を網羅した豊富なコンテンツがあります。

CSS リファレンス

CSS のすべてのプロパティや概念について記述された、熟練のウェブ開発者向けの包括的な CSS リファレンスです。


#### フロントエンドのウェブ開発者を目指している方へ

ゴールに向かって頑張るために必要な情報をまとめたコースをご用意しました。

**始めましょう**

チュートリアル
-------

CSS 学習領域 は基礎から CSS を教える複数のモジュールにスポットを当てています — 事前の知識は必要ありません。

CSS の第一歩

CSS (Cascading Style Sheets) はウェブページをスタイル付けしたりレイアウトしたりするのに使われます。例えば、文字、色、大きさを変えたり、コンテンツに余白を設けたり、複数列に分けたり、あるいはアニメーションを加えたりなど様々な装飾機能があります。このモジュールでは CSS を習得するために、どう働くかの基本とともに、構文のありかたと HTML にスタイル付けを加えることを簡単な始め方を提供します。

CSS の構成要素

このモジュールは CSS の第一歩が終わったところを引き継いでいます。言語とその構文に慣れてきて、基本的な使用経験を積んだところで、もう少し深く掘り下げてみましょう。このモジュールでは、カスケードと継承、利用可能なすべてのセレクターのタイプ、単位、寸法の調整、背景や境界のスタイル付け、デバッグなど多くのことを見ていきます。

ここでの目的は、テキストの装飾やCSS レイアウトなどのより具体的な分野に進む前に、適切な CSS を書くための手法を知り、すべての重要な理論を理解できるようになることです。

CSS テキスト装飾

CSS 言語の基本を習得したら、次に取り組むべき CSS のトピックはテキストの装飾です — これは、CSS で行う最も一般的なことの一つです。ここでは、フォント、太字、イタリック体、ラインと文字の間隔、ドロップシャドウやその他のテキスト機能の設定を含む、テキストの装飾の基本を見ていきます。あなたのページにカスタムフォントを適用し、リストとリンクを装飾するところを見ることによって、このモジュールを締めくくります。

CSS レイアウト

現段階で、すでに CSS の基本、テキストの装飾方法、コンテンツを格納するボックスの装飾方法と操作方法を見てきました。今度は、ビューポートからの相対でボックスを適切な場所に配置する方法、および互いの配置方法を検討します。必要な前提知識をカバーしているので、さまざまな表示の設定、フレックスボックス・CSS グリッド・位置指定などの最新のレイアウトツール、そしてまだ知っておきたいと思うかもしれない過去のテクニックのいくつかを見ながら、CSS レイアウトについて深く掘り下げることができます。

CSS を使ってよくある問題を解決する

このモジュールは、ウェブページを作成する際の一般的な問題を解決するための CSS の使用方法を説明するコンテンツの節へのリンクを提供しています。

リファレンス
------

* CSS リファレンス: CSS のすべてのプロパティや概念について記述された、熟練のウェブ開発者向けの CSS リファレンスです。
* CSS の主要な概念:
    + 言語の構文と書式
    + 詳細度と継承とカスケード
    + CSS 単位と値および関数記法
    + ボックスモデルとマージンの相殺
    + 包含ブロック
    + 重ね合わせとブロック整形コンテキスト
    + 初期値、計算値、使用値、実効値
    + CSS 一括指定プロパティ
    + CSS フレックスボックスレイアウト
    + CSS グリッドレイアウト
    + CSS セレクター
    + メディアクエリー
    + アニメーション
料理帳
---

CSS レイアウト料理帳は、よくあるレイアウトパターンや、サイトに実装する必要がある可能性がある事柄のレシピを共有するためのものです。プロジェクトの出発点として使うことができるコードを提供することに加えて、これらのレシピは様々な方法のレイアウト仕様書を使用することができることに光を当て、開発者として選択ができるようにします。

CSS 開発のためのツール
-------------

* W3C CSS Validation Service は CSS が正しく書かれているかを判定するために利用できます。デバッグのために重宝するツールです。
* Firefox Developer Tools はインスペクターとスタイルエディターツールを通じて、ページの CSS をライブでの閲覧や編集を可能にします。
* Firefox のウェブ開発者拡張機能では、表示しているサイトをその場で追跡したり編集したりすることができます。
メタバグ
----

* Firefox: Firefox バグ 1323667
関連情報
----

* CSS のデモ: 最新の CSS テクノロジーの例を探索して想像力をかきたてましょう。
* CSS がよく適用されるウェブ言語。HTML、SVG、MathML、XHTML、XML
* CSS に関する Stack Overflow の質問
MathML
======

**Mathematical Markup Language (MathML)** は、数学的表記を記述し、その構造と内容を表現するための XML マークアップ言語です。

このページには、MathML のパワフルな技術を用いた仕事を助けるための文書、サンプル、ツールへのリンクがあります。簡単な概要は、Mozilla Summit 2013 で行われた innovation fair 向けのスライド をご覧ください。

MathML リファレンス
-------------

MathML 要素リファレンス

各 MathML 要素の詳細とデスクトップおよびモバイルのブラウザの互換性情報。

MathML 属性リファレンス

MathML 要素の見た目や振る舞いを変更する MathML 属性についての情報。

MathML の例

MathML の動作についての理解を深めるためのサンプルと例。

MathML の書き方

MathML を書くための提案とヒント、おすすめの MathML エディター、その出力をウェブコンテンツへ統合する方法。

コミュニティから助けを得る
-------------

* mozilla.dev.tech.mathml Google Group
* Mozilla 貢献者の使う Wiki
* W3C Math Home
* www-math w3.org メールアーカイブ
ツール
---

* W3C Validator
* Mathzilla Firefox アドオンコレクション
* TeXZilla — Javascript で書かれた LaTeX から MathML へのコンバーター (ライブデモ、Firefox アドオン、ウェブページや JS プログラム内での使用)
* LaTeXML - LaTeX ドキュメントを HTML+MathML ウェブページへ変換
* MathJax - 数式のためのクロスブラウザー JavaScript 表示エンジン。MathJax をネイティブ MathML で使用するには、Mozilla アドオン、Safari 拡張、GreaseMonkey スクリプト を試してください。
関連トピック
------

* CSS
* HTML
* SVG
ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
ウェブアプリマニフェスト
============

**ウェブアプリマニフェスト**は、プログレッシブウェブアプリ (PWA) と呼ばれる一連のウェブ技術の一部であり、アプリストアを通さずに端末のホーム画面にインストールすることができるものです。単純なホーム画面リンクやブックマークを持つ通常のウェブアプリとは異なり、 PWA は事前にダウンロードしてオフラインでも動作するだけでなく、通常の Web API を使用することもできます。

ウェブアプリマニフェストは、ウェブアプリケーションについて、ウェブアプリをダウンロードしたり、ユーザーにネイティブアプリと同じように見せる（例えば、端末のホーム画面にインストールされ、ユーザーに素早いアクセスと豊かな操作性を提供するなどの）ために必要な情報を JSON テキストファイルで提供します。 PWA のマニフェストには、その名前、作者、アイコン、バージョン、説明、および (他のものの中で特に) 必要なすべてのリソースのリストが含まれています。

メンバー
----

ウェブマニフェストには、以下のキーを設定することができます。それぞれのリンクをクリックすると詳細情報を見ることができます。

* background\_color
* categories
* description
* display
* display\_override
* icons
* id
* name
* orientation
* prefer\_related\_applications
* protocol\_handlers
* related\_applications
* scope
* screenshots
* share\_target
* short\_name
* shortcuts
* start\_url
* theme\_color
マニフェストの例
--------


```json
{
  "$schema": "https://json.schemastore.org/web-manifest-combined.json",
  "name": "HackerWeb",
  "short\_name": "HackerWeb",
  "start\_url": ".",
  "display": "standalone",
  "background\_color": "#fff",
  "description": "読みやすいハッカーニュースアプリです。",
  "icons": [
    {
      "src": "images/touch/homescreen48.png",
      "sizes": "48x48",
      "type": "image/png"
    },
    {
      "src": "images/touch/homescreen72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "images/touch/homescreen96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "images/touch/homescreen144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "images/touch/homescreen168.png",
      "sizes": "168x168",
      "type": "image/png"
    },
    {
      "src": "images/touch/homescreen192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ],
  "related\_applications": [
    {
      "platform": "play",
      "url": "https://play.google.com/store/apps/details?id=cheeaun.hackerweb"
    }
  ]
}
```

マニフェストの展開
---------

ウェブアプリマニフェストは、文書の `<head>` 内の `<link>` 要素を使用して HTML ページから展開されます。


```html
<link rel="manifest" href="manifest.json" />
```


`.webmanifest` の拡張子が仕様書の Media type registration の節で指定されています（マニフェストファイルのレスポンスは `Content-Type: application/manifest+json` を返してください）。ブラウザーは一般に `.json` (`Content-Type: application/json`) のような他の適切な拡張子でもマニフェストに対応します。

マニフェストへのアクセスに資格情報が必要な場合は、マニフェストファイルが現在のページと同じオリジンにあったとしても、 `crossorigin` 属性を `use-credentials` に設定する必要があります。


```html
<link rel="manifest" href="/app.webmanifest" crossorigin="use-credentials" />
```

スプラッシュ画面
--------

一部のブラウザー（例えば Chrome 47 以降）では、ホーム画面からサイトが起動されるとスプラッシュ画面が表示されます。スプラッシュ画面はウェブアプリマニフェストのプロパティから、具体的には以下のように自動生成されます。

* `name`
* `background_color`
* `icons` の配列中のアイコンで、端末の 128dpi に最も近いもの。
仕様書
---

| 仕様書 |
| --- |
| Web App Manifest |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* プログレッシブウェブアプリ (PWA)
イベントの扱い (概要)
============

イベントとは、ブラウザーや OS の環境の変化を知らせる信号で、ブラウザーのウィンドウ内で発行されます。プログラマーは、イベントが発行されたときに実行される*イベントハンドラー*のコードを作成することで、ウェブページが変化に適切に対応できるようになります。

このページでは、イベントとイベントハンドラーの扱い方について、ごく簡単な「覚え書き」を提供しています。初めての方は、イベント入門をお読みください。

イベントでは何ができるのか
-------------

イベントは、そのイベントを発行させる JavaScript オブジェクトのページの中や下に記述されています。例えば、ブラウザーのウィンドウや現在の文書で発生したイベントを確認するには、 `Window` や `Document` のイベントの節を参照してください。

イベントのリファレンスを使用すると、アニメーションやメディアなどの特定の API に対してどの JavaScript オブジェクトがイベントを発行するかを調べることができます。

イベントハンドラーの登録
------------

ハンドラーの登録には、推奨される方法が 2 つあります。イベントハンドラーのコードは、ターゲットとなる要素の対応する *onevent* プロパティに割り当てて、イベントが起動されたときに実行されるようにするか、 `addEventListener()` メソッドを使用して、ハンドラーを要素のリスナーとして登録するかすることができます。いずれの場合も、ハンドラーは `Event` インターフェイス (または派生インターフェイス) に準拠したオブジェクトを受け取ります。主な違いは、イベントリスナーのメソッドを使うと、複数のイベントハンドラーを追加 (または削除) できることです。

**警告:** 第 3 の方法として、 HTML の onevent 属性を使ってイベントハンドラーを設定する方法がありますが、お勧めしません。これはマークアップを膨張させ、可読性を低下させ、デバッグを困難にします。詳しくは、インラインイベントハンドラーを参照してください。

### onevent プロパティの使用

慣習上、イベントを発行する Javascript オブジェクトには、それに対応する "onevent" プロパティ (イベント名の前に "on" を付けて命名) があります。これらのプロパティは、イベントが発行されたときに、関連するハンドラーコードを実行するために呼び出されます。

イベントハンドラーのコードを設定するには、適切な onevent プロパティに代入してください。 1 つの要素のそれぞれのイベントに対して、割り当てることができるイベントハンドラーは 1 つだけです。必要に応じて、同じプロパティに別の関数を代入することで、ハンドラーを置き換えることができます。

以下の例では、 `greet()` 関数を `click` イベントに割り当てるために `onclick` プロパティを使用しています。


```js
const btn = document.querySelector("button");

function greet(event) {
  // print the event object to console
  console.log("greet:", arguments);
}

btn.onclick = greet;
```


なお、イベントハンドラーの第一引数には、イベントを表すオブジェクトが渡されます。このイベントオブジェクトは、 `Event` インターフェースを実装しているか、またはそれを継承しています。

### EventTarget.addEventListener

要素にイベントハンドラーを設定する最も柔軟な方法は、 `EventTarget.addEventListener` メソッドを使用することです。この方法では、複数のリスナーを 1 つの要素に割り当てることができ、必要に応じて (`EventTarget.removeEventListener` を使用して) リスナーを削除することができます。

**メモ:** イベントハンドラーの追加と削除ができることで、例えば、同じボタンで状況によって異なるアクションを実行することができます。また、より複雑なプログラムでは、古い、使われていないイベントハンドラーを整理することで、効率を上げることができます。

以下では、単純な `greet()` 関数をクリックイベントのリスナーまたはイベントハンドラーとして設定する方法を示します (必要に応じて、名前付き関数の代わりにラムダ関数を使用することもできます)。繰り返しますが、イベントは、イベントハンドラーの第一引数として渡されます。


```js
const btn = document.querySelector("button");

function greet(event) {
  // print the event object to console
  console.log("greet:", arguments);
}

btn.addEventListener("click", greet);
```


このメソッドは、イベントのキャプチャおよび削除の制御をするために、追加の引数/オプションを取ることもできます。詳細については、 `EventTarget.addEventListener` のリファレンスページを参照してください。

#### 中止シグナルの使用

イベントリスナーの注目すべき機能は、中止シグナルを使って複数のイベントハンドラーを同時にクリーンアップできることです。

これは、同じ `AbortSignal` を、一緒に削除できるようにしたいすべてのイベントハンドラーの `addEventListener()` 呼び出しに渡すことで行われます。その後、 `AbortSignal` を所有するコントローラーで `abort()` を呼び出すと、そのシグナルで追加されたすべてのイベントハンドラーが削除されます。例えば、 `AbortSignal` で削除できるイベントハンドラーを追加するには、次のようにします。


```js
const controller = new AbortController();

btn.addEventListener(
  "click",
  function (event) {
    // イベントオブジェクトをコンソールに表示
    console.log("greet:", arguments);
  },
  { signal: controller.signal },
); // このハンドラーに AbortSignal を渡す
```


上記のコードで生成したイベントハンドラーは、次のようにして削除することができます。


```js
controller.abort(); // このコントローラーに関連付けられたすべてのイベントハンドラーを削除
```
プロキシサーバーとトンネリング
===============

インターネットのさまざまなネットワークを移動するときに、プロキシサーバーと HTTP トンネルは、 World Wide Web 上のコンテンツへのアクセスを容易にしています。プロキシはユーザーのローカルコンピュータ、またはユーザーのコンピュータとインターネット上の送信先サーバーの間の任意の場所に配置できます。このページではプロキシに関するいくつかの基本を概説し、いくつかの設定オプションを紹介します。

プロキシには、**フォワードプロキシ** (またはトンネルまたはゲートウェイ) と**リバースプロキシ** (負荷分散、認証、復号化またはキャッシュ用のサーバーへのアクセスを制御および保護するために使用される) の 2 種類があります。

フォワードプロキシ
---------

フォワードプロキシ、またはゲートウェイ、または単に「プロキシ」は、クライアントまたはクライアントグループにプロキシサービスを提供します。インターネットには数十万もの公開プロキシが存在する可能性があります。グループによって使用される帯域幅を減らして制御するために、インターネットサービス (DNS や Web ページなど) を格納して転送します。

フォワードプロキシは匿名プロキシにすることもでき、ユーザーは Web をブラウズしたり他のインターネットサービスを使用している間に自分の IP アドレスを隠すことができます。TOR (The Onion Router) は、匿名性のために複数のプロキシを介してインターネットトラフィックをルーティングします。

リバースプロキシ
--------

その名前が示すように、リバースプロキシはフォワードプロキシとは逆の動作を行います。フォワードプロキシはクライアント (またはリクエストホスト) に代わって動作し、リバースプロキシはサーバーに代わって動作します。フォワードプロキシはクライアントの ID を隠すことができますが、リバースプロキシはサーバの ID を隠すことができます。リバースプロキシにはいくつかの利用法がありますが、一部を紹介します。

* ロードバランシング: 複数のウェブサーバーに負荷を分散すること
* 静的なコンテンツのキャッシュ: 写真のような静的コンテンツをキャッシュすることによってウェブサーバーの負荷を軽減すること
* 圧縮: コンテンツを圧縮して最適化し、読み込み時間を短縮すること
プロキシを介してクライアント情報を転送する
---------------------

プロキシは、プロキシの IP アドレスから発信されたようにリクエストを表示させることができます。 これはクライアントの匿名性を提供するためにプロキシを使用する場合に便利ですが、それ以外の場合は元のリクエストの情報が失われます。 元のクライアントの IP アドレスは、デバッグ、統計、またはロケーション依存のコンテンツの生成によく使用されます。 この情報を公開する一般的な方法は、次の HTTP ヘッダーを使用することです。

標準化されたヘッダー:

`Forwarded`

プロキシがリクエストのパスに含まれているときに、変更または失われたクライアント側のプロキシサーバー側からの情報が含まれます。

あるいは事実上の標準バージョン:

`X-Forwarded-For` 
Non-standard

HTTP プロキシまたはロードバランサーを介してウェブサーバーに接続しているクライアントの発信元 IP アドレスを識別します。

`X-Forwarded-Host` 
Non-standard

クライアントがプロキシまたはロードバランサーへの接続に使用した元のホストを識別します。

`X-Forwarded-Proto` 
Non-standard

クライアントがプロキシまたはロードバランサーへの接続に使用したプロトコル (HTTP または HTTPS) を識別します。

(クライアントへの接続ではなく) プロキシ自体に関する情報を提供するには、`Via` ヘッダーを使用できます。

`Via`

プロキシによって、フォワードとリバースの両方のプロキシが追加され、リクエストヘッダーとレスポンスヘッダーに表示されます。

HTTP トンネリング
-----------

トンネリングはデータをカプセル化することによって、パブリックネットワークを介してプライベートネットワークデータおよびプロトコル情報を送信します。 HTTP トンネリングは、より低いレベルのプロトコル (TCP) を伝送するために、より高いレベル (HTTP) のプロトコルを使用しています。

HTTP プロトコルは `CONNECT` と呼ばれるリクエストメソッドを指定します。リクエストされたリソースとの双方向通信を開始し、トンネルを開くために使用することができます。これは、HTTP プロキシの背後にあるクライアントが SSL (つまり HTTPS、443 番ポート) を使用してウェブサイトにアクセスする方法です。ただし、すべてのプロキシサーバーが `CONNECT` メソッドに対応していたり、443 番ポートのみに限定したりしているわけではないことに注意してください。

Wikipedia の HTTP トンネルの記事も参照してください。

プロキシの自動設定 (PAC)
---------------

プロキシ自動設定 (PAC) ファイルは、ウェブブラウザーのリクエスト (HTTP、HTTPS、および FTP) を直接宛先に送信するか、ウェブプロキシサーバーに転送するかを決定する JavaScript 関数です。PAC ファイルに含まれる JavaScript 関数は、次の関数を定義します。

auto-config ファイルは拡張子が `.pac` のファイルに保存する必要があります。
```

proxy.pac
```


MIME タイプは次のように設定されています。
```

application/x-ns-proxy-autoconfig
```


このファイルは `FindProxyForURL` という関数で構成されています。以下の例は、内部 DNS サーバーが内部ホスト名のみを解決できるように設定されている環境で動作し、解決できないホストに対してのみプロキシを使用することを目標としています。


```js
function FindProxyForURL(url, host) {
  if (isResolvable(host)) return "DIRECT";
  else return "PROXY proxy.mydomain.com:8080";
}
```


他の例についてはプロキシ自動設定 (PAC) を参照してください。

関連情報
----

* `CONNECT`
* Proxy server on Wikipedia
リソースと URI
=========

HTTP により、ブラウザーやその他のユーザーエージェントは、インターネット上の様々な*リソース*と通信することができます。このために、ブラウザーはリソースの*識別*および*場所*の両方が必要です。これら二つの情報が URI によって記述されます。

ウェブ上のリソースの識別

URI およびウェブ上のリソースへのアクセス方法です。

データ URI

特定の種類の URI である、識別子の中にリソース自体を埋め込んだデータ URI です。

www および www 以外の URL の選択

www の接頭辞が付いたドメインを使用するかどうかのアドバイスで、この記事では選択の結果がどうなるかと、どうするかを説明します。

MIME タイプ

MIME メディアタイプは、特定のリソースがどの種類の文書であるかを定義します。この記事は構文と、ウェブでよく使われる MIME タイプを紹介します。

よくある MIME タイプ

ウェブ開発者に便利なよくある MIME タイプの一覧です。

リソースの識別子と位置の分離: Alt-Svc ヘッダー

識別子と位置の両方が URL で記述されていますが、この 2 つは異なる概念であり、時には区別したほうが便利です。この記事では `Alt-Svc` ヘッダーを紹介します。
HTTP の基本
========

HTTP はとても拡張性のあるプロトコルです。リソースの記述や URI などわずかな基本概念に基づいており、メッセージ構造が単純で、コミュニケーションの流れはクライアント・サーバー構造です。これらの基本概念の上に、いくつもの拡張が何年にもわたって行われ、新しい機能や新しい意味が新しい HTTP メソッドやヘッダーによって追加されています。

記事
--

HTTP の概要

HTTP とは何であるか、そしてウェブアーキテクチャにおけるこのプロトコルの役割について説明します。

HTTP の進化

HTTP は 1990 年代初めに作成され、何度も拡張されました。この記事では、 HTTP/0.9、 HTTP/1.0、 HTTP/1.1、現代の HTTP/2、および長年にわたり導入されている小さなノベルティについての歴史を説明します。

HTTP バージョンのネゴシエーション

クライアントとサーバーが特定の HTTP バージョンをネゴシエートし、最終的に使用されたプロトコルバージョンをアップグレードする方法を説明します。

リソースと URI

ウェブ上のリソース、識別子、および場所の概念を簡単に紹介します。

ウェブ上のリソースの識別

ウェブリソースの参照方法とどのように配置されるのかについて説明します。

データ URI

それが表すリソースを直接埋め込む特定の種類の URI。データ URI はとても便利ですが、いくつかの注意点があります。

リソース URL 
Non-standard

`resource:` というスキームの接頭辞が付いた URL は、 Firefox と Firefox のブラウザー拡張機能によってリソースを内部的に読み込むために使用されますが、情報の一部はブラウザーが接続するサイトでも利用できます。

リソースの識別と場所の分離: Alt-Svc HTTP ヘッダー

ほとんどの場合、ウェブリソースの識別子と場所は共有されますが、これは `Alt-Svc` ヘッダーで変更できます。

MIME タイプ

HTTP/1.0 以降では、様々なタイプのコンテンツを送信することができます。 この記事では `Content-Type` ヘッダーと MIME 標準を使用してこれがどのように行われるかについて説明します。

www URL とそうでない URL の選択

www という接頭辞のドメインを使うかどうかに関するアドバイスで、この記事では選択の結果とその作成方法について説明します。

HTTP セッションの流れ

この基本的な記事では典型的な HTTP セッションについて説明します。ブラウザーのリンクをクリックすると、何が起こるのでしょうか

HTTP メッセージ

HTTP リクエストまたはレスポンス中に送信されるメッセージは、非常に明確な構造を持っています。この入門記事ではその構造、目的、可能性について説明します。

HTTP/2 でのフレームとメッセージ構造

HTTP/2 は HTTP/1.x メッセージをカプセル化し、バイナリフレームで表現します。この記事ではフレームの構造、目的、エンコード方法について説明します。

HTTP/1.x でのコネクション管理

HTTP/1.1 は持続的な接続とパイプライン処理をサポートする HTTP の最初のバージョンでした。この記事ではこれらの 2 つの概念について説明します。

HTTP/2 でのコネクション管理

HTTP/2 では接続の作成方法とメンテナンス方法が完全に再考されました。この記事では HTTP フレームが多重化を許可し、以前の HTTP バージョンの 'head-of-line' ブロック問題を解決する方法について説明します。

コンテンツネゴシエーション

HTTP はブラウザーが好みの形式、言語、またはエンコーディングをアナウンスするための方法として `Accept-` から始まる一連のヘッダを導入しています。この記事ではこの宣言がどのように起こるか、サーバがどのように反応すると予想され、どのように最も適切な応答を選択するかについて説明します。
HTTP リクエストメソッド
==============

HTTP では、リソースに対して実行したいアクションを示す一連の**リクエストメソッド**を定義しています。リクエストメソッドは *HTTP 述語*と呼ばれることがありますが、名詞も存在します。それぞれのメソッドがさまざまな意味を持っていますが、いくつかの共通的な機能が、メソッドのグループで共有されています。例えば、リクエストメソッドは安全、べき等、キャッシュ可能であることがあります。

`GET`

`GET` メソッドは、指定したリソースの表現をリクエストします。 `GET` を使用するリクエストは、データの取り込みに限ります。

`HEAD`

`HEAD` メソッドは `GET` リクエストと同じレスポンスを、レスポンス本文なしで求めます。

`POST`

`POST` は指定したリソースに実体を送信するために使用するメソッドであり、サーバー上の状態を変更したり、副作用が発生したりすることがよくあります。

`PUT`

`PUT` メソッドは対象リソースの現在の表現全体を、リクエストのペイロードで置き換えます。

`DELETE`

`DELETE` メソッドは、指定したリソースを削除します。

`CONNECT`

`CONNECT` メソッドは、対象リソースで識別されるサーバーとの間にトンネルを確立します。

`OPTIONS`

`OPTIONS` メソッドは、対象リソースの通信オプションを示すために使用します。

`TRACE`

`TRACE` メソッドは、対象リソースへのパスに沿ってメッセージのループバックテストを実行します。

`PATCH`

`PATCH` メソッドは、リソースを部分的に変更するために使用します。

仕様書
---

| 仕様書 | 表題 | 備考 |
| --- | --- | --- |
| RFC 7231, セクション 4: Request methods | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE を定義。 |
| RFC 5789, セクション 2: Patch method | PATCH Method for HTTP | PATCH を定義。 |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* HTTP ヘッダー
Cross-Origin Resource Policy (CORP)
===================================

**クロスオリジンリソースポリシー**は `Cross-Origin-Resource-Policy` ヘッダーによって設定されるポリシーで、ウェブサイトやアプリケーションが他のオリジンから (`<script>` や `<img>` などの要素を使用して発行された) 特定のリクエストに対する保護をオプトインすることで、 Spectre のような投機的なサイドチャネル攻撃や、クロスサイトスクリプトインクルージョン攻撃を緩和することができます。

CORP は既定で same-origin policy を超えた保護の追加レイヤーです。クロスオリジンリソースポリシーは、既定でクロスオリジンの読み込みを保護するメカニズムである、 クロスオリジンリードブロッキング (CORB)を補完します。

**メモ:** このポリシーは、既定で CORS セーフリストメソッド／ヘッダーに対して発行される、`no-cors` リクエストに対してのみ有効です。

このポリシーは\*レスポンスヘッダー*を介して表現されるため、実際のリクエストは防止されません。むしろ、ブラウザーは応答本文を削除することで*結果\*が漏洩するのを防ぎます。

歴史
--

コンセプトは 2012 年に（`From-Origin`として）元々提案されましたが、2018 年の Q2 に再提案されて Safari と Chromium に実装されました。

2018 年の前半に、*Meltdown* と *Spectre* として知られる 2 つのサイドチャネルハードウェア脆弱性が公表されました。パフォーマンスを改善するために設計された投機的実行機能の一部として生じた競合状態により、これらの脆弱性は機密性の高いデータを漏洩することができます。

これを受けて Chromium は Cross-Origin Read Blocking を実装しました。これにより、クロスオリジンの読み込みに対してリソース（`Content-Type` が HTML、JSON、XML）を自動的に保護します。アプリケーションが `no-sniff` ディレクティブを渡していない場合、Chromium は `Content-Type` を推測しようと試みて、とにかく保護を適用します。

クロスオリジンリソースポリシーは*どのような*リソースでも保護することができるオプトインのレスポンスヘッダーです。ブラウザーが MIME タイプを嗅ぎ分ける必要はありません。

使用方法
----

**メモ:** Chrome のバグが原因で、クロスオリジンリソースポリシーが PDF の描画を破壊し、訪問者が PDF の 1 ページ目以降を読めない可能性があります。本番環境ではこのヘッダーの仕様には注意してください。

ウェブアプリケーションは、次の 3 つの値の中から 1 つ受け取ることができる `Cross-Origin-Resource-Policy` の HTTP レスポンスヘッダーを介してクロスオリジンリソースポリシーを設定します。

same-site

同じ *Site* からのリクエストのみリソースを読み込めます。

**警告:** これはオリジンよりも安全性が低いものです。2 つのオリジンが同じサイトであるかどうかをチェックするアルゴリズムは HTML 標準で定義されており、*登録可能なドメイン*をチェックします。

same-origin

同じ *origin* (すなわち、スキーマ + ホスト + ポート) からのリクエストのみリソースを読み込めます。

cross-origin

いかなる *origin* (same-site と cross-site 両方) からのリクエストでもリソースを読み込めます。

```

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```


クロスオリジンリソースポリシーチェックの際に、ヘッダーが設定されている場合、ブラウザーは異なるオリジンやサイトから発行された `no-cors` リクエストを拒否します。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

仕様書
---

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

関連情報
----

* `Cross-Origin-Resource-Policy` HTTP Header
* Bugzilla bug 1459573
If-Range
========

**`If-Range`** HTTP リクエストヘッダはレンジリクエストを条件付きにします：条件が満たされれば、レンジリクエストが発行され、サーバは適切なボディを持つ `206` `Partial Content` 回答を返します。条件が満たされていない場合、 `200` の状態でリソース全体が返送されます。

このヘッダは `Last-Modified` バリデータ、または `ETag` のいずれかで使用できますが、両方では使用できません。

最も一般的な使用事例は、最後のフラグメントが受信されてから格納されたリソースが変更されていないことを保証するために、ダウンロードを再開することです。

|  |  |
| --- | --- |
| ヘッダータイプ | Request header |
| Forbidden header name | いいえ |

構文
--
```

If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>
```

ディレクティブ
-------

<etag>

リクエストされたリソースを表すエンティティータグです。これは `"675af34563dc-tr34"` のようにダブルクオートに囲まれた ASCII の文字列で、弱い比較アルゴリズムを使うことを示すために `W/` がプレフィックスとしてつくことがあります。


<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

例
-
```

If-Range: Wed, 21 Oct 2015 07:28:00 GMT
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7233, セクション 3.2: If-Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match`
* `If-None-Match`
* `206` `Partial Content`
* HTTP Conditional Requests
Content-Encoding
================

**`Content-Encoding`** は表現ヘッダーで、表現（メッセージの内容）に適用されているエンコード方式とその順番を保持しています。
 これによって受信者は、元の内容の形式を取得するために、その表現をデコードする方法を知ることができます。
 コンテンツのエンコード方式は、主に元のメディア形式に関する情報を失うことなくメッセージデータを圧縮するために使用されます。

元のメディア/コンテンツの形式は `Content-Type` ヘッダーで指定し、 `Content-Encoding` はデータの表現、つまり「コード化形式」に適用されることに注意してください。元のメディアが何らかの方法でエンコードされている場合（zip ファイルなど）、この情報は `Content-Encoding` ヘッダーには含まれません。

可能な限りデータを圧縮してこのフィールドを使用することを推奨しますが、 JPEG 画像などの一部のリソースは、すでに圧縮されています。時には、さらに圧縮をしても長さが短縮されないどころか、かえって長くなることもあります。

|  |  |
| --- | --- |
| ヘッダー種別 | 表現ヘッダー |
| 禁止ヘッダー名 | いいえ |

構文
--


```http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

// 複数の場合、適用された順序
Content-Encoding: deflate, gzip
```

ディレクティブ
-------

`gzip`

Lempel-Ziv coding (LZ77) を使用し、32 ビットの CRC が付いた形式です。これは UNIX の *gzip* プログラムの独自形式です。 HTTP/1.1 標準は、このエンコード方式に対応するサーバーは、互換性の面から `x-gzip` もエイリアスとして解釈するよう推奨しています。

`compress`

Lempel-Ziv-Welch (LZW) アルゴリズムを使用した形式です。この値の名前は、このアルゴリズムを実装している UNIX の *compress* プログラムから取られました。このエンコード方式は、特許問題（2003 年に期限切れ）を一因として、 compress プログラムが多くの UNIX ディストリビューションから削除されたのと同様に、現在では多くのブラウザーから削除されています。

`deflate`

zlib 構造（RFC 1950 で定義）の deflate 圧縮アルゴリズム（RFC 1951) で定義）を使用します。

`br` 
Non-standard

Brotli アルゴリズムを使用した形式です。

例
-

### gzip での圧縮

クライアント側では、送信で使用してほしい圧縮方式のリストを HTTP リクエストで示すことができます。 `Accept-Encoding` ヘッダーを使用して、コンテンツのエンコード方式の交渉が行われます。


```http
Accept-Encoding: gzip, deflate
```


サーバーは使用した方式を、 `Content-Encoding` レスポンスヘッダーで応答します。


```http
Content-Encoding: gzip
```


なお、サーバーはどの圧縮方式も使用することを義務づけられていません。圧縮はサーバー設定や使用しているサーバーモジュールに強く依存します。

仕様書
---

| Specification |
| --- |
| HTTP Semantics # field.content-encoding |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Accept-Encoding`
* `Transfer-Encoding`
From
====

**`From`** リクエストヘッダーには、リクエスト元の user agent を制御する人のユーザーの E メールアドレスが含まれています。

ロボティックユーザーエージェント (クローラなど) を使用している場合は、`From` ヘッダーを送信する必要があります。ロボットが過度の不要なリクエストや無効なリクエストを送信しているなど、サーバーに問題が発生した場合は連絡できます。

**警告:** アクセス制御または認証には `From` ヘッダーを使用しないでください。


|  |  |
| --- | --- |
| ヘッダータイプ | Request header |
| Forbidden header name | いいえ |

構文
--
```

From: <email>
```

ディレクティブ
-------

<email>

マシンに使用可能な電子メールアドレス。

例
-
```

From: webmaster@example.org
```

仕様
--

| 仕様書 | タイトル |
| --- | --- |
| RFC 7231, セクション 5.5.1: From | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Host`