HTTPセッション。 ターミナルサーバーのリモート接続セッションのパラメータを設定するにはどうすればよいですか? もう一度、session_name()関数とsession_id()関数について
Webサーバーはクライアントへの永続的な接続を維持せず、各要求は以前の要求への接続なしで、新しい要求のように扱われます。
つまり、同じ訪問者からのリクエストを追跡したり、別々のページのビュー間で彼の変数を保存したりすることはできません。 セッションは、これら2つの問題を解決するために考案されました。
実際、セッションは、一言で言えば、ブラウザーを一意に識別し、サーバー上にこのブラウザー用のファイルを作成して、セッション変数を格納できるようにするメカニズムです。
このようなメカニズムの必要性については詳しく説明しません。 これらは、eストアのショッピングカート、承認などの教科書のケースであり、たとえば、サイトのインタラクティブな部分をスパムから保護するなど、完全に些細な問題ではありません。
原則として、セッションの独自のアナログを作成するのは非常に簡単です。組み込みのPHPほど機能的ではありませんが、本質的には似ています。 クッキーとデータベースについて。
スクリプトを要求するとき、特定の名前のCookieが到着したかどうかを確認します。 Cookieがない場合は、Cookieを設定し、ユーザーデータを含む新しい行をデータベースに書き込みます。 Cookieがある場合は、データベースから読み取ります。 もう1つのリクエストで、データベースから古いレコードを削除します。これで、セッションメカニズムの準備が整いました。 難しいことではありません。 ただし、組み込みのセッションメカニズムを使用することが望ましいニュアンスがいくつかあります。
最初のものだけが有効になっている場合は、セッションの開始時に(session_start()を呼び出すたびに)Cookieがクライアントに設定されます。 ブラウザは次のリクエストごとにこのCookieを正しく返し、PHPにはセッション識別子があります。 ブラウザがCookieを返さない場合、問題が発生します。 この場合、PHPは識別子を持つCookieを受信せずに常に新しいセッションを開始し、メカニズムは機能しません。
2番目のみが有効になっている場合、Cookieは設定されません。 そして何が起こるかというと、そのためには、基本的に、実際には、組み込みのセッションメカニズムを使用する価値があります。 スクリプトがその役割を果たし、ページが完全に形成された後、PHPはそれをすべて調べ、各リンクと各フォームにセッションIDを追加します。 これは次のようになります。
索引に変わる
索引
隠しフィールドがフォームに追加されます
また、ブラウザは、リンクをクリックするか、フォームのボタンをクリックすると、必要な変数(セッション識別子)をリクエストで送信します。
明らかな理由で、IDは相対リンクにのみ追加されます。
理論的には、Cookieとデータベースに関する自家製のセッションでは、IDの転送を手動ですべてのリンクに手動で割り当てることができます。そうすれば、独自のセッションがCookieとは独立して機能します。 しかし、ご覧のとおり、他の誰かがこの作業を行うと、より快適になりますか? ;-)
最近のバージョンのPHPでは、両方のオプションがデフォルトで有効になっています。 PHPはこれをどのように処理しますか? クックは常に展示されています。 また、PHPがセッションIDを持つCookieを検出しない場合にのみ、リンクがオートコンプリートされます。 ユーザーがこのセッション中に初めてサイトにアクセスすると、Cookieが取得され、リンクが追加されます。 次のリクエストで、Cookieがサポートされている場合、PHPはCookieを確認し、リンクの完了を停止します。 Cookieが機能しない場合、PHPは引き続きリンクにIDを適切に追加し、セッションが失われることはありません。
Cookieが機能しているユーザーには、IDの長いリンクが1回だけ表示されます。
ふー。 識別子の転送が終了しました。
これで、サーバー側のデータを含むファイルをバインドする必要があります。
PHPがこれを行います。 書くだけで十分です
session_start();
$ _SESSION ["test"] = "Hello world!";
そして、PHPはこのセッションに関連付けられたファイルにテスト変数を書き込みます。
ここには非常に重要なポイントがあります。
$ _SESSION配列は特別です。
実際、その中には、さまざまなスクリプトで使用できるようにしたい変数があります。
変数をセッションに配置するには、変数を$ _SESSION配列の要素に割り当てるだけです。
その値を取得するには、同じ要素を参照するだけで十分です。 例を以下に示します。
ガベージコレクション-PHPは、廃止されたファイルの削除にも関与しています。 データエンコーディングやその他の必要なものもたくさんあります。 このケアの結果として、セッションでの作業は非常に簡単です。
ここに、実際、セッションの作業の例があります。
例は非常に小さいです:
session_start();
echo "このページを更新しました"。$ _ SESSION ["counter"] ++。 "times。";
エコー "
アップデート ";
?>
セッションにカウンター変数があるかどうかを確認し、ない場合は、値0で作成してから、その値を出力して1つ増やします。 増加した値はセッションに書き込まれ、次にスクリプトが呼び出されたときに、変数の値は1になり、以下同様に続きます。
すべてがとてもシンプルです。
サイトの任意のページのセッション変数にアクセスするには、セッションが必要な各ファイルの先頭に1行だけ(!)を書き込む必要があります。
session_start();
次に、$ _ SESSION配列の要素を参照します。 たとえば、承認チェックは次のようになります。
session_start();
if($ _SESSION ["authorized"]<>1) {
ヘッダー( "場所:/auth.php");
出口;
}
セッションから変数を削除します。
register_globals = offの場合は、次のように記述します。
unset($ _ SESSION ["var"]);
そうでない場合は、 近く彼女と一緒に書く必要があります
session_unregister( "var");
PHPがセッションを操作しようとしたときに発生する最も一般的なエラーは次のとおりです。
それらのうちの2つ、
警告:セッションCookieを送信できません-ヘッダーはすでに送信されています
警告:セッションキャッシュリミッターを送信できません-ヘッダーはすでに送信されています
同じ理由で、解決策はこの事実で説明されています
第3、
警告:開く(/ tmp \ sess_SID、O_RDWR)に失敗しました:行番号のfull_script_pathにそのようなファイルまたはディレクトリ(2)がありません(以前は彼女は次のように見えました 警告:セッションデータ(ファイル)の書き込みに失敗しました。 session.save_pathの現在の設定が正しいことを確認してください(/ tmp)),
英語から翻訳すると、問題が詳細に説明されます。php.iniで指定されている、セッションファイルが書き込まれるディレクトリへのパスが利用できません。 このエラーは最も簡単に修正できます。 たとえば、存在して書き込み可能なディレクトリを作成するだけです。
session.save_path = c:\ windows \ temp
その後、Apacheを再起動することを忘れないでください。
結局のところ、人間の知性には限界がないので、私は説明する必要があります:
3番目のエラーメッセージ(ディレクトリが見つかりません)は、最初の2つにつながります。これは、エラーメッセージがブラウザに出力され、その後のヘッダーを使用できないためです。 したがって、早すぎる結論を急いで探すのではなく、最初に正しいパスを書いてください。
セッションを処理する際の次の最も一般的な問題は、register_globalsの大きな遺産です。 スクリプト変数に$ _SESSION配列のインデックスと同じ名前を付けないでください。
register_globals = onの場合、値は互いに上書きされ、混乱します。
また、register_globals = offの場合、別のエラーが表示されます。「スクリプトは、PHP4.2.3まで存在していたセッションの副作用に依存している可能性があります。」... これを取り除くには、使用する前に常に変数を初期化する(または少なくとも存在を確認する)必要があり、$ _ SESSION配列のインデックスと一致するグローバル変数名を付けないでください。
それが機能しないが、メッセージも表示されない場合は、スクリプトの最初に、画面にすべてのエラーを表示する責任がある2行を追加します-エラーがある可能性は十分にありますが、単に表示されません彼ら。
ini_set( "display_errors"、1);
error_reporting(E_ALL);
または、error_logのエラーを参照してください。 一般に、エラーメッセージの表示に関するトピックはこの記事の範囲を超えているため、少なくともエラーメッセージが表示されることを確認してください。 このセクションでは、トラブルシューティングの詳細をもう少し読むことができます。
エラーがないことは確かですが、与えられた例がとにかく機能しない場合は、PHPがURLを介したIDの転送を有効にしていない可能性があります。 と何らかの理由でCookieが機能しない.
あなたがクッキーで持っているものを見てください。
一般に、セッションが「機能しない」場合は、最初にセッションIDを手動で転送してみてください。つまり、リンクを作成して、それにIDを割り当てます。
session_start();
if(!isset($ _ SESSION ["counter"]))$ _SESSION ["counter"] = 0;
echo "このページを更新しました"。$ _ SESSION ["counter"] ++。 "回。
アップデート ";
?>
これを行うときは、session.use_only_cookiesディレクティブが有効になっていないことを確認してください。これにより、PHPがURLを介して渡された場合にセッションIDを受け入れることができなくなります。
この例が機能しない場合、問題は平凡なものにあります タイプミス(セッションの「問題」の半分は、スペルミスの変数名に起因します)、または古すぎるバージョンのPHP:セッションサポートはバージョン4.0で登場し、$ _ SESSION配列-4.1では(以前は$ HTTP_SESSION_VARSが使用されていました) 。
それが機能する場合、問題はCookieにあります。 サーバーがブラウザに送信しているCookieの種類、ブラウザがCookieを返すかどうかを追跡します。 ブラウザとサーバー間のHTTPヘッダー交換を確認する場合、検索は非常に便利です。
Cookieがどのように機能するかを説明することは、このすでに大きすぎるテキストの範囲を超えていますが、少なくともサーバーが識別子を使用してCookieを送信し、ブラウザーが戻ることを確認してください。 そして、識別子が互いに一致している間=)
Cookieの設定は次のようになります
Set-Cookie:PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6;
またはどのように
Set-Cookie:PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; パス= /
(ルートディレクトリからではなくスクリプトを要求している場合)
サーバーの応答は次のようになります
クッキー:PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6
また
クッキー:PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; b = b
ブラウザがセッションID以外の他のCookieを返す場合。
ブラウザがCookieを返さない場合は、Cookieがまったく機能するかどうかを確認してください。
アクセスしているドメインが通常の名前(少なくとも1つのピリオドがあり、アンダースコアなどの禁止文字が含まれていない)であることを確認し、ブラウザのキャッシュをクリアします。これらがCookieが機能しない主な理由の2つです。
ここの例が機能するが、独自のコードが機能しない場合、問題は明らかにセッションではなく、アルゴリズムにあります。 変数を失った場所を探し、ここから例を段階的に転送し、スクリプトをデバッグします。
ヘッダーリダイレクトまたはJavaScriptナビゲーションを使用している場合は、別の問題が発生する可能性があります。
実際、PHPはフォームのリンクにのみセッション識別子を自動的に追加します 、ただし、ヘッダー、javascript、メタタグに対してはこれを行いません。
したがって、たとえば次のように、識別子を手動で追加する必要があります。
ヘッダー( "場所:/script.php?"。session_name()。 "="。session_id());
また、非常にまれであり、問題の原因が完全に不明です。問題は、session.save_handler設定にファイル以外の値があることです。 そうでない場合は、修正してください。
安全性
セッションのセキュリティは広大なトピックです。 したがって、私はいくつかの主要なポイントに焦点を当てます。
最も教科書のことは、アドレスバーを介して識別子を渡さないことです。 これはphp.iniでも記述されていますが、これによりセッションの機能が制限されます。 このアドバイスに従うことにした場合は、session.use_trans_sid = 0の他に、session.use_only_cookies = 1を忘れないでください。
セッションをIPアドレスにバインドすることをお勧めします。これにより、識別子が盗まれた場合でも、ほとんどの場合、悪役はそれを使用できなくなります。
session.save_pathディレクティブを使用することをお勧めします。これを使用して、セッションファイルを保存するための独自のディレクトリを設定できます。 これは、サーバーのデフォルトの共有一時ディレクトリに保存されている場合よりも安全です。
session_cache_limiter( "private");
セッションを開始する前に問題を解決する必要があります。
セッションを使用した承認の例
上記のすべてを小さな例で説明しましょう。
auth.phpファイルを作成しましょう:
if(isset($ _ POST ["auth_name"]))
{
$ sql = "SELECT * FROM users WHERE name =?S";
$ row = $ db-> getRow($ sql、$ _POST ["auth_name"]);
if($ row && password_verify($ _POST ["auth_pass"]、$ row ["pass"]))(
$ _SESSION ["user_id"] = $ row ["id"];
}
ヘッダー( "場所:http://"。$ _SERVER ["HTTP_HOST"]。$ _ SERVER ["REQUEST_URI"]);
出口;
}
if(isset($ _ GET ["action"])AND $ _GET ["action"] == "logout")(
session_start();
session_destroy();
ヘッダー( "場所:http://"。$ _SERVER ["HTTP_HOST"]。 "/");
出口;
}
if(!isset($ _ SESSION ["user_id"]))(
?>
出口;
}
これで、保護されたすべてのスクリプトに次の行を書き込むだけで十分です。
「auth.php」が必要です。
この例では、セッションがすでに開始されており、データベースへの接続がMySQLでの安全で便利な作業のためにClassを使用して作成されていることを前提としています。 また、推奨されるpassword_hash関数を使用してパスワードがハッシュされていることを前提としています。
保護されたファイルの例:
session_start();
「safemysql.class.php」を含める;
$ db = new safemysql(["db" => "test"]);
「auth.php」を含める;
?>
秘密
ログアウト
OPS! 非常に便利なリンク:
http://www.php.net/manual/ru/ref.session.php-公式ドキュメントのPHPでのセッションサポートに関する最新の情報と、多数のユーザーコメント。 読むことを強くお勧めします。
http://phpclub.ru/manrus/f/ref.session.html-Alexander Pyramidinによって翻訳されたドキュメントからの、この章のロシア語への非常に時代遅れの翻訳。
http://phpclub.ru/detail/article/sessions
「セッションについての真実」という大げさなタイトルの記事。 それは曖昧な印象を残します。 最初に、著者はセッションメカニズムについて非常に簡単に話しますが、記事の終わりに向かって彼が提案する方法は完全に泥だらけです。
サイトのDmitryBorodinによる教科書記事
http://php.spb.ru/は強くお勧めしません。
みんな、彼女はひどく時代遅れです。 事実に誤りがあるだけでなく、PHPのセッションは長い間使用されていません。
彼女のディマに感謝します。これはロシア語でのセッションに関する最初の記事でした。私はそれを自分で勉強しましたが、今は彼女を当然の休息に送る必要があります。
また、残念ながら、インターネット上にあり、何年も更新されていない他の多くの記事も古くなっています。
セッション(ラテン語-sessio-会議、英語-セッション)は、最初のリンクが開かれた瞬間から最後のリンクまでのインターネット上でのユーザーの作業をカバーする期間です。 これは、最初のリクエストと最後のリクエストの時間差として計算されます。 ただし、ユーザーは最後のページをさまざまな時間に表示できるため、2つのリクエスト間の時間を測定することはより困難になります。
セッションがHTTPとCOOKIESにどのように関連しているか
セッションとは、HTTPプロトコルの観点から説明できます。 このプロトコル自体は、2つの操作間で状態を永続化する方法を提供しません。 つまり、1つのページを開いてから別のページに移動することにより、HTTPは両方の要求が同じユーザーに属していることを確認できません。 そして、ここで特別な追跡方法が救いの手を差し伸べます-セッション管理(私たちのセッション)。
したがって、セッションとは何かという質問に答えると、それは1人のユーザーからの連続するHTTP要求間のデータ転送を容易にする補助論理オブジェクトであると言えます。
Cookieは、セッションと同様に、ユーザーがさまざまなページをナビゲートするときにユーザーに関する情報を保存し、プロトコルの操作を改善します。 ただし、データがサーバー上の一時ファイルに保存される2番目の方法とは異なり、データは小さなフラグメントの形でユーザーのコンピューターに保存されます。
セッションとは何ですか?
フォーラム、掲示板、オンラインストアなどのサイトで作業する場合は、ユーザーデータを複数のページに保存する必要があるため、セッションの使用が不可欠になります。
セッションステージ
セッション全体は、次の3つの段階に分けることができます。
- セッションを開く(ユーザーが特定のサイトで作業を開始したとき)、
- セッション変数の説明(別のページに移動する場合)、
- セッションの終了。
セッションデータはサードパーティのサーバーに保存されるため、大量の情報を保存するのではなく、Cookieを使用することをお勧めします。
PHPでのセッション、またはサイトにアクセスしたユーザーや顧客に関するデータが、サイトのページ間を移動するときにどのように保存されるかについては、それほど問題はありません。 レッスンはとても重要です。 サイトの95%の作成に関連します。
PHPのセッションとは
セッションは、同じサイトのページ間を移動するときに、一時データに関する情報(たとえば、ユーザーがサイトに入ったという情報)を保存するために使用されます。 セッションを使用する場合、データはサーバー上の一時ファイルに保存されます。ほとんどの場合、セッション(およびCookieも)は、オンラインストア、フォーラム、メッセージボード、ソーシャルネットワーク、ブログ、およびその他のリソースを作成するときに使用されます。 セッションシステムの便利さは、ログインしたユーザー/顧客の一時的な情報を保存することにあり、そのデータは一定時間すばやくアクセスできます。 セッションには、ブラウザが閉じられるまで、自然な有効期限があります。 ページのみを閉じた場合、サイトを開いたときに、ユーザー/購入者に関するデータは引き続き利用できます。
セッションロジック
セッション(またはセッション)は、一時的なデータストレージの一種です。 少量のデータを保存する価値があることをすぐに警告します。 たとえば、ログインしているユーザーのログインとパスワード、またはデータベース内の彼のシリアル番号。仕事の例
1.
ユーザーがユーザー名とパスワードを入力してサイトに入る
2.
ログインとパスワードを含むデータは、サイトのいずれかのページのセッションに保存されます。
ファイル index.php
Session_start(); //セッションデータを使用する各ファイルには、コードの先頭に「セッションの開始」コマンドが含まれている必要があります
$ login = "admin";
$ password = "pass";
$ _SESSION ["login"] = $ login; //ログインを含む変数を保存します
$ _SESSION ["password"] = $ password; //パスワードを含む変数を保存します
3. サイトの別のページに移動すると、このデータも利用できるようになります。
ファイル example.php(または他のページ)
「あなたのログイン」をエコーします。$ _ SESSION ["login"]; //このページにはデータを記録していませんが、「ログインは管理者です」と表示されます。
ほら、簡単です!
4. セッションデータをクリアしたい場合は、それで十分です。
ファイル example.php
Session_start(); //「セッションを開始」します
設定解除($ _ SESSION ["login"]); //これは、変数が登録解除または「破棄」された方法です
echo "あなたのログイン"。$ _ SESSION ["login"]; //「あなたのログイン」を表示します。 最後の行で破壊したので、データもありません。
Session_destroy(); //セッションを破棄します。 $ _SESSION ["password"]を含むすべてのデータが失われました。 要求されると、エラーが表示されます
一般に、このような転送はPOST方式に似ていますが、不要なコードを大量に記述する必要がなくなり、ページ間で転送されるすべてのデータがサーバー上の一時ファイルに保存されます。 繰り返しになりますが、セッションには少量のデータが含まれている必要があるため、ユーザー名/パスワード、ショッピングカート、その他の少量のデータを保存するのに適しています。
PHPセッションを使用して値または配列を渡す
セッションでは、文字列だけでなく、データの配列も書き込むことができます。 アレイのサイズでやりすぎないでください。これはすべて、サーバーのパフォーマンスと占有スペースに影響します。再び特定のスタートページを使用します index.php
Session_start();
$ r = array( "one"、 "two"、 "three");
$ _SESSION ["arr"] = $ r;
すべてが表示されているページへ
セッションにデータを保存し、別のページへのリンクをたどると、すべてのデータが表示されます。
ファイル受信者、ページ test.phpアレイを開く場所
Session_start();
print_r($ _ SESSION ["arr"]);
//出力します
/*
配列
=> 1つ
=> 2つ
=> 3
*/
?>
のチュートリアルをブラッシュアップすることをお勧めします。 一般的に、すべてが明確でなければなりません。
セッションを操作するための他の関数
session_unregister(文字列)-セッションは、指定されたグローバル変数の値を忘れます。session_destroy()-セッションが破棄されます(たとえば、ユーザーがログアウトボタンを押してシステムを離れた場合)。
session_set_cookie_params(int Lifetime [、string path [、string domain]])-この関数を使用すると、セッションの終了時刻を決定するunix_timestampを設定することにより、セッションの存続期間を設定できます。
PHPでセッション(セッション)を操作するための関数のリスト
session_cache_expire-現在のキャッシュの有効期限を返します
session_cache_limiter-現在のキャッシュ制限を取得および/または設定します
session_commit-session_write_close()のエイリアス
session_decode-文字列からセッションデータをデコードします
session_destroy-セッションに登録されているすべてのデータを破棄します
session_encode-現在のセッションデータを文字列として暗号化します
session_get_cookie_params-セッションCookieパラメータを取得します
session_id-現在のセッションIDを取得および/または設定します
session_is_registered-変数がセッションに登録されているかどうかを判別します
session_module_name-現在のセッションのモジュールを取得および/またはインストールします
session_name-現在のセッションの名前を取得および/または設定します
session_regenerate_id-現在のセッションIDを新しく生成されたもので変更します
session_register-現在のセッションの1つ以上の変数を登録します
session_save_path-現在のセッションを保存するためのパスを取得および/または設定します
session_set_cookie_params-セッションCookieパラメータを設定します
session_set_save_handler-ユーザーレベルのセッションストレージ関数を設定します
session_start-セッションデータを初期化します
session_unregister-現在のセッションから変数の登録を解除します
session_unset-すべてのセッション変数を解放します
session_write_close-セッションデータとセッションの終了を書き込みます
セッションの例
セッション中のページビューのカウンター。 仕事の実例。 ただし、ブラウザを閉じた後、カウントダウンが最初からやり直されます。1つのセッション内の1つのページへの訪問のカウンター
// Cookieなしでセッションを使用する簡単な例。
session_name( "test");
session_start();
$ _SESSION ["count"] = @ $ _ SESSION ["count"] + 1;
?>
カウンター
ブラウザを使用した現在の作業セッションで、このページを開きました
=$_SESSION["count"]?>時間(秒)。
ブラウザを閉じて、このカウンタをリセットします。
ページを更新するには、ここをクリックしてください。
遷移するたびに、カウンターは1ずつ増加します。
ご清聴ありがとうございました! あなたの努力で頑張ってください!
HTTPはクライアントサーバープロトコルであるため、HTTPセッションは次の3つのフェーズで構成されます。
- クライアントはTCP接続(またはTCPトランスポートが使用されていない場合は別の接続)を確立します。
- クライアントは要求を送信し、応答を待ちます。
- サーバーは要求を処理し、ステータスコードと関連データを含む応答を送信します。
HTTP / 1.1以降、第3フェーズの後、クライアントは別の要求を開始できるため、接続は閉じられません。 つまり、2番目と3番目のフェーズを繰り返すことができます。
接続の確立
HTTPはクライアントサーバープロトコルであるため、接続は常にクライアントによって確立されます。 HTTPで接続を開くということは、適切なトランスポート(通常はTCP)を介して接続を確立することを意味します。
TCPの場合、ポート80がコンピューターのデフォルトのHTTPサーバーポートとして使用されますが、8000や8080などの他のポートもよく使用されます。ロードされたページのURLには、ドメイン名とポートが含まれますが、省略できます。デフォルトのポートと一致する場合。
つまり:クライアント/サーバーモデルは、サーバーがデータを明示的に要求せずにクライアントにデータを送信することを防ぎます。 この問題を回避するために、Web開発者はさまざまな手法を使用します。XMLHTTPRequestJavascriptオブジェクト、HTML WebSockets API、または同様のプロトコルを使用してサーバーに定期的にpingを実行します。
顧客リクエストの送信
接続が確立されると、ユーザーエージェントはリクエストを送信できます。 (ユーザーエージェントは通常Webブラウザーですが、そうでない場合もあります)クライアント要求は、CRLF(改行)で区切られたテキストディレクティブです。 リクエスト自体には次の3つのブロックが含まれます。
- 最初の行には、リクエストメソッドとそのパラメータが含まれています。
- ドキュメントへのパス-プロトコルとドメイン名を指定しない絶対URL
- HTTPプロトコルバージョン
- 後続の各行はHTTPヘッダーであり、優先データのタイプ(たとえば、どの言語、どのMIMEタイプ)またはサーバーの動作を変更する命令(たとえば、応答がない場合は応答を送信しない)に関する情報をサーバーに送信します。すでにキャッシュにあります)。 これらのHTTPヘッダーは、空の行で終わるブロックを形成します。
- 最後のブロックはオプションであり、追加のデータが含まれています。 主にPOSTメソッドで使用されます。
リクエストの例
サイトのメインページを取得し、可能であれば、ユーザーエージェントがフランス語のページを好むことをサーバーに通知します。
GET / HTTP / 1.1ホスト:サイト承認-言語:fr
データブロックとヘッダーブロックを区切る最後の空白行に注意してください。 リクエストにはContent-Length:HTTPヘッダーが含まれていないため、データブロックは空であり、サーバーはヘッダーの終わりを示す空の文字列を受信するとすぐにリクエストの処理を開始できます。
フォーム送信の結果を送信します。
POST /contact_form.php HTTP / 1.1ホスト:サイトContent-Length:64 Content-Type:application / x-www-form-urlencoded name = Joe%20User&request = Send%20me%20one%20of%20your%20catalogue
リクエストメソッド
HTTPは、リソースに対する目的のアクションを示す一連の要求メソッドを定義します。 名詞にすることもできますが、これらのリクエストメソッドはHTTPコマンドと呼ばれることもあります。 最も一般的なGETおよびPOSTリクエストは次のとおりです。
- GETは、指定されたリソースのコンテンツを要求するために使用されます。 GETを使用するリクエストは、データのみを受信する必要があります。
- POSTメソッドは、サーバーの状態を変更できるようにデータをサーバーに送信します。 このメソッドは、HTMLフォームによく使用されます。
サーバーの応答構造
接続されたエージェントが要求を送信した後、Webサーバーはそれを処理して応答を送信します。 クライアント要求と同様に、サーバー応答はCRLFで区切られたテキストディレクティブであり、3つの異なるブロックにグループ化されます。
- 最初の行(ステータス行)は、使用されているHTTPバージョンとリクエストのステータス(および人間が読める形式の値)の確認で構成されます。
- 後続の行は、送信されるデータに関する情報(タイプ、サイズ、圧縮アルゴリズム、キャッシュヒントなど)をクライアントに提供するHTTPヘッダーです。 クライアントリクエストと同様に、これらのHTTPヘッダーは、空の行で終了するブロックを形成します。
- 最後のブロックにはデータが含まれています(存在する場合)。
サンプル応答
成功したWebページの取得:
HTTP / 1.1 200 OK日付:2010年10月9日土曜日14:28:02 GMTサーバー:Apache最終変更日:2009年12月1日火曜日20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges:bytesコンテンツの長さ:29769コンテンツの種類:テキスト/ html(ここでは、要求されたWebページの29769バイトになります)
要求されたリソースが移動されたというメッセージ:
HTTP / 1.1 301恒久的に移動サーバー:Apache / 2.2.3(Red Hat)コンテンツタイプ:text / html; charset = iso-88 59-1日付:2010年10月9日土曜日14:30:24 GMT場所: (これは要求されたリソースの新しいアドレスであり、クライアントはそれを要求することが期待されます) キープアライブ:タイムアウト= 15、最大= 98受け入れ範囲:バイト経由:Moz-Cache-zlb05接続:キープアライブX-Cache-Info:キャッシングX-Cache-Info:キャッシングContent-Length:325 (コンテンツには、クライアントがリンクをたどることができない場合に表示される標準ページが含まれています)
恒久的に移動
文書はここに移動しました。
ポート80サイトのApache / 2.2.3(Red Hat)サーバー
要求されたリソースが存在しないというメッセージ: