We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

索引

MDN の HTTP ページ

このページは概要やタグに沿った MDN のすべての HTTP ページの一覧です。

64 ページあります:

# ページ タグと要約
1 HTTP HTTP, Reference, Web, l10n:priority
Hypertext Transfer Protocol (HTTP) は HTML などのハイパーメディア文書を転送するための、アプリケーション層プロトコルです。これはウェブブラウザーとウェブサーバーの間の通信用に設計されていますが、他の用途でも使用できます。 HTTP は伝統的なクライアントサーバモデルに従い、クライアントがコネクションを開き、要求を送信し、応答を受け取るまで待ちます。また HTTP は ステートレスプロトコルであり、サーバーは2つの要求の間でいかなるデータ (状態) も保持しません。 HTTP は多くの場合 TCP/IP 層をベースにしますが、任意の信頼性があるトランスポート層プロトコル、すなわち UDP のように暗黙のうちにメッセージを捨てることがないプロトコルで使用することもできます。
2 Basics of HTTP HTTP, NeedsTranslation, Overview, TopicStub
HTTP is a pretty extensible protocol. It relies on a few basics concepts like the notion of resources and URIs, a simple structure of messages, and a client-server structure for the communication flow. On top of these basics concepts, numerous extensions have appeared over the years, adding new functionality and new semantics by creating new HTTP methods or headers.
3 HTTP の進化 Guide, HTTP
HTTP は World Wide Web を支えるプロトコルです。Tim Berners-Lee によって 1989-1991 年に発明されれてから、HTTP にはシンプルさのほとんどを維持しながら柔軟性をさらに形作る、多くの変更がみられます。HTTP は初期のいくぶん信頼された研究所の環境内でファイルを交換するプロトコルから、現代のインターネットの迷宮で高解像度や 3D の画像や動画を運ぶプロトコルに進化しました。
4 MIME タイプ Content-Type, Guide, HTTP, MIME タイプ, エンティティヘッダー
MIME タイプは、文書の性質や形式を示すための標準化された方法です。 IETF RFC 6838 で定義及び標準化されています。 Internet Assigned Numbers Authority (IANA) がすべての公式な MIME タイプを追跡し続ける責任のある公式な主体であり、最新の完全なリストは Media Types ページで見ることができます。
5 MIME タイプの不完全な一覧 HTTP, MIME タイプ, コンテンツ, テキスト, リファレンス, 動画, 音声
これはドキュメントのタイプに関連付けられている MIME タイプの一覧であり、一般的な拡張子の昇順に並べています。
6 data URIs Base64, Guide, Intermediate, URI, URL
data: スキームが先頭についている URL である data URI を使うと、コンテンツ製作者は小さなファイルをインラインで文書に埋め込むことができます。
7 www URL か非 www URL かを選択する Guide, HTTP, URL
ウェブサイトの管理者の間で繰り返される質問が、www URL と非 www URL のどちらを選択するかです。このページでは、何が最良かについてアドバイスを提供します。
8 ウェブ上のリソースの識別 HTTP
HTTP 要求の対象は「リソース」と呼ばれ、その本質は細かく定義されていません。ドキュメント、写真、その他の何にでもなりえます。それぞれのリソースは、リソースを特定するために HTTP の至るところで使用される Uniform Resource Identifier (URI) で特定されます。
9 Content Security Policy (CSP) CSP, Content Security Policy, Reference, Security
Content Security Policy (CSP) とは、クロスサイトスクリプティング (XSS) やデータを差し込む攻撃などといった、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。
10 Gecko ユーザエージェント文字列リファレンス Compatibility, Firefox, Firefox 4, Gecko, Gecko 2.0, Guide
この文書では、Firefox 4 以降および Gecko 2.0 以降ベースのアプリケーションで用いるユーザエージェント文字列について説明します。Gecko 2.0 での変更点について詳しくは Final User Agent string for Firefox 4 (blog 記事) をご覧ください。ユーザエージェントの検出に関する文書や Hacks の投稿もご覧ください。
11 HTTP Pipelining FAQ Necko
HTTP/1.1 パイプライン化 FAQ
12 HTTP のリダイレクション Guide, HTTP, redirects
URL リダイレクションまたは URL 転送は、ページ、フォーム、ウェブアプリケーション全体といった実際のリソースが異なる URL に存在していてもリンクを存続させる技術です。サイトをメンテナンスしている間の一時的なリダイレクト、サイトの構成を変更した後も外部のリンクを機能させるための恒久的なリダイレクト、ファイルをアップロードしているときの進捗を示すページなど、さまざまな目的で使用されるこの操作を実行するために、HTTP は特別なレスポンスである HTTP リダイレクトを提供しています。
13 HTTP の圧縮 Content Negotiation, Guide, HTTP
圧縮は、ウェブサイトのパフォーマンスを向上させるための重要な手段です。ドキュメントによっては、必要な帯域を最大 70% 削減するほどサイズが縮減します。長年かけてアルゴリズムはより効率的になり、またクライアントおよびサーバーが新たなアルゴリズムをサポートしました。
14 HTTP の概要 HTML, HTTP, Overview, WebMechanics, 概要
HTTP は、 HTML 文書などのリソースを取り出すことを可能にするプロトコルです。これはウェブにおけるデータ交換の基礎をなすクライアントサーバープロトコルであり、リクエストは受け取り者 (一般にはウェブブラウザー) が生成します。文書全体は、テキスト、レイアウトの定義、画像、動画、スクリプトなど、取り込まれたさまざまなサブ文書から再構成されます。
15 HTTP キャッシュ Caching, Guide, HTTP
過去に取得したリソースを再使用すると、ウェブサイトやアプリケーションのパフォーマンスが大きく向上するでしょう。ウェブキャッシュは遅延やネットワークのトラフィックを削減して、リソースを表示するために必要な時間も短縮します。HTTP キャッシュを使用すると、ウェブサイトの応答性が高まります。
16 HTTP クッキー Cookies, Guide, HTTP, クッキー
HTTP クッキー (ウェブクッキー、ブラウザークッキー) は、サーバーがユーザーのウェブブラウザーに送信する小さなデータであり、ブラウザーに保存されて次のリクエストと共に同じサーバーへ返送されます。
17 HTTP ヘッダー HTTP, HTTP ヘッダー, Networking, Reference, header, ヘッダー
HTTP ヘッダーは、クライアントやサーバーが要求や応答で追加情報を渡すことを可能にします。 HTTP ヘッダーは、大文字小文字を区別しないヘッダー名とそれに続くコロン ':'、 (改行なしの) 値で構成されます。値の前にあるホワイトスペース文字は無視されます。
18 Accept-Language HTTP, HTTP ヘッダー, Reference, コンテンツネゴシエーション
HTTP の Accept-Language リクエストヘッダーは、クライアントがどの言語を理解できるか、どの種類のロケールが推奨されるかを示します。（言語というのは、英語のような自然言語を意味し、プログラミング言語ではありません。）コンテンツネゴシエーションを使用して、サーバーは提案されたものから一つを選択して使用し、 Content-Language レスポンスヘッダーを使用してクライアントに選択結果を知らせます。ブラウザーはユーザーインターフェイスの言語に従って、このヘッダーに適切な値を設定し、ユーザーはこれを変更することができますが、稀です（そして指紋につながるとして難色を示されます）。
19 Access-Control-Allow-Headers CORS, HTTP, ヘッダー, リファレンス, 応答ヘッダー
Access-Control-Allow-Headers 応答ヘッダーは、プリフライト要求への応答で、実際の要求の間にどの HTTP ヘッダーが使用できるかを示すために使用されます。
20 Access-Control-Allow-Origin Access-Control-Allow-Origin, CORS, HTTP, HTTP ヘッダー, アクセス制御, オリジン, オリジン間問題, セキュリティ, ヘッダー, リファレンス, 応答ヘッダー
Access-Control-Allow-Origin 応答ヘッダーは、応答が与えられたオリジンとリソースを共有できるかどうかを示します。
21 Cache-Control HTTP, HTTP ヘッダー, Reference, 一般ヘッダー
Cache-Control 一般ヘッダフィールドはリクエストとレスポンス両方のキャッシュルールを指定するために用います。キャッシュの指定は一方的で、つまり、リクエストの定義がレスポンスの定義と同じにはなりません。
22 Connection HTTP, Web, ヘッダー, リファレンス
Connection 一般ヘッダーは現在のトランザクションが完了したあとも、ネットワーク接続を開いたままにするかどうかを制御します。もし keep-alive がこのヘッダーの値として設定されて送信されると、接続が維持されて閉じられなくなり、同一のサーバーに送るべき後続のリクエストで再利用されます。
23 Content-Disposition HTTP, Reference, header
multipart/form-data ボディにおける Content-Disposition ヘッダーは、マルチパートを構成する各サブパートに付与し、そのフィールドに関する情報を示します。サブパートはContent-Type ヘッダーで定義された boundary によって区切られます。マルチパートボディ全体に付与した場合、 Content-Disposition は何の意味も持ちません。
24 Content-Type Content-Type, HTTP, エンティティヘッダー, ヘッダー, リファレンス
Content-Type エンティティヘッダーは、リソースのメディア種別を示すために使用します。
25 Cookie HTTP, Reference, cookie, クッキー, ヘッダー, 禁止ヘッダー名, 要求ヘッダー
HTTP の Cookie 要求ヘッダーは、以前サーバーが Set-Cookie ヘッダーで送信し、保存された HTTP クッキーを含みます。
26 DNT DNT, HTTP, Reference, header
DNT (Do Not Track) リクエストヘッダーは、ユーザーのトラッキングの設定を示します。 これにより、ユーザーはパーソナライズされたコンテンツではなく、プライバシーを優先するかどうかを指定できます.
27 Expect-CT HTTP, ヘッダー, リファレンス, 応答ヘッダー
Expect-CT ヘッダーは、サイトが認証透過性の要件の報告や強制に参加して、サイトの不正な認証情報が通知されない状態を防ぐことができます。サイトが Expect-CT ヘッダーを有効にすると、ブラウザーが公開 CT ログに現れるサイトのすべての認証情報をチェックするよう要求します。
28 Host HTTP, Reference, ヘッダー, 要求ヘッダー
Host 要求ヘッダーは（仮想ホストの）サーバーのドメイン名及び (任意で) サーバーが待受けしている TCP のポート番号を指定します。
29 If-Modified-Since
HTTPリクエストヘッダIf-Modified-Since はリクエストを条件付にします。サーバは最後にリソースが編集された時刻が、リクエストにより与えられた時刻より後の場合にのみ、リクエストされたリソースを200 と共に返却します。もしリクエストにより与えられた時刻以降にリソースが変更されていなければ、レスポンスはボディを持たず304が返却されます。Last-Modified は最後にリソースが変更された時刻を含みます。If-Unmodified-Sinceと異なり、If-Modified-SinceはGETもしくはHEADでのみ使用できます。
30 Last-Modified
HTTPレスポンス ヘッダLast-Modifiedは、最後にリソースに対する変更があったとオリジンサーバが考える日付と時刻を含みます。これは受信したリソースが既にストア済みなのか、そうでないかを判定するためのバリデータとして用いられます。ETagヘッダより精度は低く、ETagヘッダが存在しない場合に本ヘッダでの検証が行われます。条件付リクエストIf-Modified-Since やIf-Unmodified-Since は本フィールドを用いて作成されます。
31 Origin HTTP, Reference, header
Origin 要求ヘッダーは、フェッチの起点を示します。 パス情報は含まれず、サーバー名のみが含まれます。 これは、 CORS リクエストと POST リクエストと一緒に送信されます。 これは Referer ヘッダーと似ていますが、このヘッダーとは異なり、パス全体が公開されるわけではありません。
32 Server
Server ヘッダーには、要求を処理するオリジンサーバが使用するソフトウェアについての情報が含まれます。
33 Transfer-Encoding HTTP, ヘッダー, リファレンス, 応答ヘッダー
Transfer-Encoding ヘッダーは、エンティティをユーザーに安全に転送するために使われる符号化の形式を指定します。
34 HTTP メッセージ Guide, HTTP, WebMechanics
HTTP メッセージは、サーバーとクライアントがデータを交換する手段です。クライアントが送信してサーバーにアクションを起こさせるリクエストと、サーバーの回答であるレスポンスの、2 種類のメッセージがあります。
35 HTTP リクエストメソッド HTTP, Methods, Reference, メソッド
HTTP では、リソースに対して実行したいアクションを示す一連のリクエストメソッドを定義しています。リクエストメソッドは名詞も存在しますが、 HTTP 動詞と言われることがあります。それぞれのメソッドがさまざまな意味を持っていますが、いくつかの共通的な機能が、メソッドのグループで共有されています。例えば、リクエストメソッドは安全、べき等、キャッシュ可能であることがあります。
36 GET HTTP, Reference, リクエストメソッド
HTTP の GET メソッドは、特定のリソースの表現をリクエストします。 GET を使用したリクエストはデータを受け取るだけです。
37 TRACE
HTTP の TRACE メソッドは、対象リソースまでのパスに沿ってメッセージのループバックテストを行い、便利なデバッグの仕組みを提供します。
38 HTTP 応答状態コード HTTP, HTTP 状態コード, 状態コード
HTTP 応答状態コードは、特定の HTTP 要求が正常に完了したかを示します。応答は情報応答、成功応答、リダイレクト、クライアントエラー、サーバーエラーの 5 つのクラスに分類されます。状態コードはRFC 2616 の第10章で定義されています。
39 200 OK
HTTP 200 OK はリクエストが成功した場合に返すレスポンスコード。200のレスポンスはデフォルトでキャッシュしてよい。
40 201 Created HTTP, ステータスコード, リファレンス
HTTP 201 Created successステータスは、リクエストが成功しリソースの作成が完了したことを表すレスポンスコードです。レスポンスが返される前に新たなリソースが作成され、レスポンスメッセージの本文にて新しいリソースが返されます。その位置はリクエストURLか、またはLocationヘッダーのコンテンツとなります。
41 202 Accepted HTTP, ステータスコード, リファレンス
HTTP 202 Accepted レスポンスはリクエストを受け取ったが処理はされていない、ということを表すステータスコードです。これはコミットされていない、リクエストを処理した結果を示すレスポンスを、非同期で送信する方法がHTTPに存在しないことを意味しています。別のプロセスまたはサーバーがリクエストを処理する場合、またはバッチ処理の場合を想定しています。
42 203 Non-Authoritative Information
HTTP 203 Non-Authoritative Information レスポンスステータスは、リクエストが成功したが、変換proxyによって元のサーバーの200 (OK) レスポンスからペイロードが変更されたことを表しています。
43 204 No Content HTTP, Reference, Status code, Success
HTTP のレスポンスコード 204 No Content は、リクエストが成功した事を示しますが、クライアントは現在のページから遷移する必要はありません。レスポンスコード 204 が返された場合は、デフォルトでキャッシュ可能になっています。そのようなレスポンスには、ETag ヘッダーが含まれています。
44 206 Partial Content HTTP, HTTP Status, Range Requests, Success
HTTP の成功ステータス応答コード 206 Partial Content は、その要求が成功したこと、そして要求ヘッダの Range に記述された、要求されている範囲のデータが body に含まれていることを示します。
45 303 See Other HTTP, HTTP 状態コード, リダイレクト, リファレンス
HTTP の 303 See Other リダイレクト状態応答コードは、リダイレクトが新しくアップロードされたリソースではなく、確認ページやアップロード進捗ページのような別なページにリンクすることを示します。この応答コードはふつう、 PUT 又は POST の結果として送り返されます。このリダイレクトページを表示するためには、常に GET を使用してください。
46 400 Bad Request
HTTP 400 Bad Request は、サーバーが不正な構文によりリクエストを解釈できなかったことを示すレスポンスコードです。
47 401 Unauthorized
HTTP 401 Unauthorized は、有効な認証資格が不足していることによりリクエストが適用されないことを示すクライアントエラーのレスポンスコードです。
48 403 Forbidden
HTTP 403 Forbidden は、サーバーがリクエストを拒否していることを示すクライアントエラーのレスポンスコードです。
49 404 Not Found HTTP, クライアントエラー, ステータスコード
HTTP 404 Not Found は、サーバーがリクエストされたリソースを見つけることができない時のクライアントエラーのレスポンスコードです。404ページにつながるリンクは、壊れたリンクまたは死んだリンクと呼ばれ、リンク腐敗の影響を受ける可能性があります。
50 405 Method Not Allowed
HTTP 405 Method Not Allowed レスポンスステータスコードはリクエストメソッドがサーバー側で確認されたが、サーバー側で無効に設定されていることを示します。サーバーは必須であるGET とHEADの2つのメソッドを無効に設定してはならず、この2つのメソッドに対して405 Method Not Allowed を返すべきではありません。
51 409 Conflict
HTTP 409 Conflict はリクエストが現在のサーバーの状態と競合したことを示すステータスコード。
52 410 Gone Client error, HTTP, Reference, Status code
ハイパーテキスト転送プロトコル (HTTP) の 410 Gone クライエントエラー応答コードは、元のサーバーで利用できなくなっている対象リソースにアクセスしていることを示します。この状態は永久的です。
53 418 I'm a teapot
HTTP 418 I'm a teapot は、サーバーが、自身がティーポットであることを理由としてコーヒーを入れることを拒否することを示すクライアントエラーのレスポンスコードです。このエラーは、1998年におけるエイプリルフールのジョークであるHyper Text Coffee Pot Control Protocolに由来します。
54 HTTP 条件付きリクエスト Conditional Requests, Guide, HTTP
HTTP には条件付きリクエストの概念があり、影響を受けるリソースと検証子の値を比較することによって、リクエストが成功した場合でもリクエストの結果を変更できます。このようなリクエストはダウンロードを再開するとき、あるいはサーバー上のドキュメントでアップロードや変更を行うときに更新内容を失うことを避けるときなどに、ドキュメントの整合性を確認するためにキャッシュの内容を検証して無駄な制御を避けるために役立ちます。
55 HTTP/1.x のコネクション管理 Guide, HTTP, Performance, WebMechanics
コネクション管理は、 HTTP の重要なトピックです。コネクションを開いたり管理したりすることは、ウェブサイトやウェブアプリケーションのパフォーマンスに大きな影響を与えます。HTTP/1.x では短命な (short-lived) コネクション、持続的な (persistent) コネクション、HTTP パイプラインといったモデルがあります。
56 Link prefetching FAQ Gecko, HTML, HTTP, Link, Necko, Performance, Web Development, 先読み, 移行
リンクの先読みとはブラウザーの機能の一つで、ブラウザーのアイドル時間を使って、ユーザーが近い将来に訪問するであろう文書をダウンロードして、予め読み込んでおくことを指します。まず、Web ページの方から先読みのヒントをブラウザーに渡します。そのページの読み込みが完了すると、ブラウザーは黙って指定された文書を先読みし、キャッシュに蓄積しておきます。ユーザーが先読みされている文書を訪問すると、ブラウザーのキャッシュからすぐに提供できます。
57 Proxy servers and tunneling HTTP, HTTP Tunneling, NeedsTranslation, Proxies, Proxy, TopicStub
When navigating through different networks of the Internet, proxy servers and HTTP tunnels are facilitating access to content on the World Wide Web. A proxy can be on the user's local computer, or anywhere between the user's computer and an destination server on the Internet. This page outlines some basics about proxies and introduces a few configuration options.
58 プロキシ自動設定ファイル Necko, PAC, ネットワーク, プロキシー
設定を表す文字列を返します. 返す文字列の形式は下の戻り値形式で定義されています.
59 User Agentを用いたブラウザの判定
Serving different Web pages or services to different browsers is usually a bad idea. The Web is meant to be accessible to everyone, regardless of which browser or device they're using. There are ways to develop your website to progressively enhance itself based on the availability of features rather than by targeting specific browsers.
60 X-Frame-Options Apache, Gecko, HAProxy, HTTP, Security, nginx, セキュリティ, 応答ヘッダー
HTTP の X-Frame-Options 応答ヘッダーは、ブラウザーがページを <frame>, <iframe>, <object> の中に表示することを許可するかどうかを示すために使用されます。サイトはコンテンツが他のサイトに埋め込まれないよう保証することで、クリックジャッキング攻撃を防ぐためにこれを使用することができます。
61 オリジン間リソース共有 (CORS) AJAX, CORS, Fetch, Fetch API, HTTP, HTTP アクセス制御, NeedsBrowserAgnostic, Security, XMLHttpRequest, l10n:priority, オリジン間リソース共有, セキュリティ, 同一オリジンポリシー
オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、追加の HTTP ヘッダーを使用して、ユーザーエージェントが現在のサイトとは別のオリジン (ドメイン) のサーバーから選択されたリソースにアクセスする権限を得られるようにする仕組みです。
62 コンテンツネゴシエーション Content Negotiation, HTTP, Reference
HTTP においてコンテンツネゴシエーション (content negotiation) は、同じ URL に対してさまざまなバージョンのリソースを提供するために使用する仕組みであり、ユーザーエージェントはどのリソースがユーザーにもっとも適しているか (例えばドキュメントの言語、画像の形式、コンテンツのエンコード方式) を指定できます。
63 典型的な HTTP セッション HTTP
HTTP のようなクライアントサーバープロトコルでは、セッションが 3 つの段階で構成されます。
64 索引 HTTP, Index
このページは概要やタグに沿った MDN のすべての HTTP ページの一覧です。

ドキュメントのタグと貢献者

タグ: 
このページの貢献者: mfuji09
最終更新者: mfuji09,