diff --git a/files/ja/web/http/overview/index.md b/files/ja/web/http/overview/index.md index dbaef08e397dcd..95f2c2f88acb6a 100644 --- a/files/ja/web/http/overview/index.md +++ b/files/ja/web/http/overview/index.md @@ -2,7 +2,7 @@ title: HTTP の概要 slug: Web/HTTP/Overview l10n: - sourceCommit: eada29e0774d505becb3a725001d372f0dbdc73d + sourceCommit: a75c144eaba00c38623b2ab9532319b1da40825f --- {{HTTPSidebar}} @@ -56,7 +56,7 @@ HTTP はアプリケーション層の最上位に存在します。 ### ウェブサーバー 通信路の反対側は、クライアントのリクエストに応じて文書を*提供する*サーバーがいます。 -サーバーは、仮想的には 1 台だけのマシンとして見えます。しかし、実際は負荷を共有する(負荷分散の)ための複数のサーバーの集合体である場合もありますし、他のコンピューター(キャッシュ、データベースサーバー、電子商取引サーバーなど)に問い合わせを行う複雑なひとまとまりのソフトウェアを分け合って、リクエストに応じて全面的または部分的に文書を生成していることもあります。 +サーバーは、仮想的には 1 台だけのマシンとしてしか見えませんが、実際には負荷を分担する(ロードバランシング)サーバーの集合であったり、他にも(キャッシュ、データベースサーバー、電子商取引サーバーなど)、要求に応じて文書を全体的または部分的に生成するソフトウェアであったりします。 サーバーは 1 台のマシンである必要性はありませんが、複数のサーバーのソフトウェアインスタンスを同じマシンで運用することができます。 HTTP/1.1 と {{HTTPHeader("Host")}} ヘッダーによって、同じ IP アドレスを共有できます。 @@ -118,24 +118,24 @@ HTTP の拡張性により時間をかけて、ウェブの制御性や機能性 HTTP で制御できる一般的な機能は以下のとおりです。 -- _[キャッシュ](/ja/docs/Web/HTTP/Caching)_ +- _[キャッシュ](/ja/docs/Web/HTTP/Caching)_: 文書をどのようにキャッシュするかを、 HTTP で制御できます。 サーバーはプロキシーやクライアントに対して、何をどれだけの間キャッシュするかを指示できます。 クライアントは中間のキャッシュプロキシーに対して、保存されている文書を無視するよう指示できます。 -- _オリジン制約の緩和_ +- _オリジン制約の緩和_: のぞき見や他のプライバシー侵害を避けるため、ウェブブラウザーはウェブサイト間を厳密に分割するよう強制しています。 **同一オリジン**のページだけが、ウェブページの情報すべてにアクセスできます。 この制約はサーバーにとって負担になりますが、 HTTP ヘッダーでサーバー側の厳密な分割を緩和できます。これにより、さまざまなドメインを情報源とした情報の寄せ集めの文書を作成できます。ただし、このようにするセキュリティ上の理由があります。 -- _認証_ +- _認証_: 特定のユーザーしかアクセスできないように保護されたページがあるでしょう。 基本的な認証は HTTP が提供しており、 {{HTTPHeader("WWW-Authenticate")}} などのヘッダーを使用するか、 [HTTP Cookie](/ja/docs/Web/HTTP/Cookies) を使用した特別なセッションを設定するかします。 -- _[プロキシーとトネリング](/ja/docs/Web/HTTP/Proxy_servers_and_tunneling)_ +- _[プロキシーとトンネリング](/ja/docs/Web/HTTP/Proxy_servers_and_tunneling)_: サーバーやクライアントがイントラネット内に配置されて、他のコンピューターから本当の IP アドレスが見えなくなっていることがよくあります。 このネットワーク境界を渡るため、 HTTP リクエストはプロキシーを通過します。 すべてのプロキシーが HTTP プロキシーであるとは限りません。 たとえば、 SOCKS プロトコルはより低い層で動作します。 ほかにも FTP などがそれらのプロキシーで処理されることがあります。 -- _セッション_ +- _セッション_: HTTP Cookie を使用して、リクエストとサーバーのセッションを関連付けできます。 これにより HTTP がステートレスプロトコルであるにもかかわらず、セッションを作成できます。 これは電子商取引のショッピングバスケットだけでなく、出力内容にユーザー設定を適用できるサイトでも有用です。 @@ -196,7 +196,7 @@ HTTP リクエストの例です。 - HTTP [メソッド](/ja/docs/Web/HTTP/Methods)。通常、クライアントが実行したい操作を定義する {{HTTPMethod("GET")}} や {{HTTPMethod("POST")}} のような動詞か、{{HTTPMethod("OPTIONS")}} や {{HTTPMethod("HEAD")}} のような名詞です。 一般的にクライアントはリソースを取り込む(`GET` を使用)か [HTML フォーム](/ja/docs/Learn/Forms) の値を送信する(`POST` を使用)ことを望みますが、場合によってはほかの操作が必要になります。 -- 取り込むリソースのパス。状況から明らかであればリソースの URL はこの要素から取り除かれます。たとえば{{Glossary("protocol","プロトコル")}}(`http://`)、{{Glossary("domain","ドメイン")}}(ここでは `developer.mozilla.org`)、TCP {{Glossary("port","ポート")}}(ここでは `80`)が取り除かれます。 +- 取り込むリソースのパス。状況から明らかであればリソースの URL はこの要素から取り除かれます。たとえば{{Glossary("protocol","プロトコル")}} (`http://`)、{{Glossary("domain","ドメイン")}}(ここでは `developer.mozilla.org`)、TCP {{Glossary("port","ポート")}}(ここでは `80`)が取り除かれます。 - HTTP プロトコルのバージョン。 - サーバーに追加の情報を与える任意の[ヘッダー](/ja/docs/Web/HTTP/Headers)。 - `POST` のようなメソッドではレスポンスと同様に、送信するリソースを包含した本体があります。