この記事では、上記のコード、上記のリンク: HTTPの変換を行います。
記事ディレクトリ
1. ウェブサイトジャンプを実装する
ブラウザに「w3school」と入力して検索します
url はリンク、
Link text は text/button を表し
、指定した Web サイトにジャンプできます。
Index.html に、Baidu リンクを表す行を追加し、Visit W3School テキストをクリックして入力します。
実行可能プログラムを実行した後、「W3School にアクセス」テキストをクリックできます。
百度へのリンクをindex.htmlに貼り付けるので、クリックすると百度のWebサイトに直接ジャンプします
独自の Web サイトへのジャンプを実装する
このとき、Baidu の URL を自分で実装した file1 と file2 のファイルに変更します。
このとき、ホストのIP+ポート番号を入力すると、図の下にfile1とfile2という2つのリンクが表示されます。
このとき、ホストのIP+ポート番号を入力します。画像の下にfile1とfile2という2つのリンクがあるのがわかります。
それぞれfile1とfile2をクリックすると、異なるWebサイトにアクセスできます。
2.リクエストメソッド(get)&レスポンスメソッド(post)
最も一般的に使用されるメソッドは GET と POST です。これらは通常
、ブラウザ クライアントによって開始され、http リクエストを構築します。伝達されるメソッドは GET/POST である場合があり、
ブラウザにリソースの送信とリクエストに異なるメソッドを使用するよう
に促し、 HTML フォームの概念
GETメソッド
クリックして表示: HTML フォーム
構文は form タグで、/form で終わる
入力ボックスを形成するため、ユーザーは個人情報を直接抽出してサーバーに送信できます。
アクションはフォームを /a/b/c.exe に送信することを意味し、対応するメソッドは GET です。
GET メソッドを使用して、名前とパスワードを入力し、最後に「送信」をクリックして送信します。
名前とパスワードを入力して「送信」をクリックすると、ジャンプページのURLはhttp://101.43.252.143:8989/a/b/c.exe?myname=dname&mypasswd=123456となります。
Linuxでも表示される
ブラウザが「送信」をクリックすると、HTTP リクエストが自動的に作成されます
。区切りとして、左側がアクセス対象のリソース、右側がリソースに与えたいパラメータであり、パラメータはKV型です。
GET は URL 経由でパラメータを送信することもできます。
POSTメソッド
他のすべてを変更せずに、メソッドを POST に変更します。
POST リクエスト、データ送信時にボディ部分を通じてパラメータを送信する
GETとPOSTの応用シナリオ
GET メソッドによって送信されたパラメータはプライベートではない (安全ではない) ため
、ブラウザの URL にパラメータをエコーします。
パラメータを送信するとき、POST メソッドはよりプライベートです。
パラメータは URL にエコーされません。
そのため、すべてのログインおよび登録アクティビティではパラメータを送信するために POST メソッドを使用する必要があります (安全ではありません)。
url: http リクエスト ラインの文字列には通常、サイズ制限があります。理論上、テキストは非常に大きくなる可能性があります。
大きなデータには POST を使用し、小さなデータには GET を使用することをお勧めします。
3. HTTPステータスコード
返された結果が正しいか間違っているかをブラウザに伝えるため
前のコードでは、ステータス コードが 200 であることをブラウザに直接伝えていますが、これは正しいです。
HTTP サーバーでは、ステータス コードは 1 から始まる、2 から始まる、3 から始まる 5 つのカテゴリに分類されます。4から始まる、5から始まる
1 で始まる情報ステータス コードを情報ステータス コードと呼びます。
例: 現在送信アクションが行われていますが、このアクションには時間がかかります。クライアントにできるだけ早く応答を返すために、1 から始まるステータス コードを返します。 1 が返され、
現在のリクエストが受け入れられ、できるだけ早く処理されていることを示します。
2 で始まるステータス コードは成功ステータス コードと呼ばれ
、一般的に使用されるのは 200 で、これはリクエストが成功したことを意味し、返された応答が正常に解釈できることを意味します。
3 で始まるコードは、リダイレクト ステータス コード(301、302、307 など)と呼ばれます。リダイレクトは、永続的なリダイレクトと一時的なリダイレクトに分けられます。
4 は、次のようなクライアント エラー ステータス コードと呼ばれます
: 404 403
例: JD.com をクリックして表示します: JD.com 公式 Web サイト
www.jd/a/b/c.htmlを探してください。このページは京東省に存在しないため、エラーが報告されます。したがって、404 エラーはクライアント エラーであり、クライアントが不正なリクエストを行っていることを示します。クライアントが不正なリクエストを行っている場合、サーバーはクライアントに、そのリクエストは不当であると伝える必要があります
私が設計したコードで 404 が見つかりました
私が設計したコードでは、アクセスされたリソースが Web サイトに見つからない場合、404 をどのように処理すればよいでしょうか?
そこで、wwwroot ディレクトリにファイルerr_404.htmlを作成します。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>404 Not Found</title>
</head>
<body>
<h1>404 Not Found</h1>
<p>Sorry, the page you are looking for could not be found.</p>
</body>
</html>
インターネット上で 404 HTML Web ページのソース コードを見つけました
Main.cc の HandlerHttp コールバック関数内
ReadFile 関数 (ファイル全体の内容を読み取る機能) が true を返した場合、ファイルが正常に読み取られたことを意味します。
ReadFile 関数の戻り値が false の場合、ファイルの読み取りに失敗したため、404 ページを追加する必要があることを意味します。
404 ページのパスを表す文字列 page_404 を作成します。
ファイルを開けない場合は、404 に対応するパスを本文 (ペイロード) にインポートします。
GetContentType関数(特定のリソースのサフィックスを判定する関数)では、.htmlであることが直接判定されます。
実行可能プログラムにポート番号 8888 が入力されている場合、ブラウザはホスト IP + ポート番号のみを入力できることを意味します。ブラウザがホスト IP + ポート番号を入力した後、
他のものを入力すると、結果は 404 になります。エラー。
5 で始まるサーバー エラー ステータス コードが呼び出されます。
サーバー上でプロセスやスレッドを作成する際、作成処理やスレッドの処理が失敗した場合、
または操作を実行した際にファイルは存在するがファイルのオープンや読み込みに失敗した場合もサーバーエラーとなります。 。
通常、サーバエラーが発生した場合でも、5で始まるステータスコードは表示されませんが、1～4で始まるステータスコードが表示されます。
3で始まるステータスコード（リダイレクトステータスコード）
主に 301、302、307 の 3 つのステータス コードを確認します。301 は
永続的なリダイレクトを意味し、
302 と 307 は一時的なリダイレクトを意味します。
永続的なリダイレクトと一時的なリダイレクトの違い
サーバーにはメーカーが Alibaba Cloud から Tencent Cloud に変更されたなどの理由があります
が、ユーザーはまだ古いサーバーにリクエストを行う可能性があることを知りません。
現時点では、現在のホストはサービスを提供しません。ただし、クライアントに「新しいアドレスにアクセスする必要がある」と通知する
ため、クライアントは新しいサーバーにアクセスするための 2 番目のリクエストを開始します。この動作はリダイレクト
と呼ばれます。
例: あなたの学校の東門に○○マラタンレストランがあります。あなたとあなたの友達は寮にいます。
あなたの学校の東門には、入り口に道路があります。この道路は建設中ですが、あなたはまだ歩いて行けるので、あなたと友達は食事のためにマラタンレストランに行きました
数か月後、お二人はまた麻辣タンを食べたいとおっしゃっていました
が、その時、麻辣湯の入り口に一枚の紙が貼られていて、入り口の道路工事のため、当店の食事環境はあまり良くありませんでした。
お二人が麻辣湯をとても食べたかったので、お店を西門に移動しました。暑かったので、西門に行きました。
この動作はリダイレクトと呼ばれます
XXXマラタンは一時的な移動なので、いつ東門に戻るか分からないので、マラタンを食べるたびに東門に行って確認しなければなりません。西門に行って麻辣湯を食べる この動作は一時リダイレクト
と呼ばれます(毎回古いアドレスに移動し、古いアドレスから新しいアドレスにジャンプします)一時的なリダイレクトではブラウザのアドレス情報は変更されません。
その後、麻辣堂店のオーナーは、西門のほうが学校の寮に一番近いため、西門の方が東門よりも業績が良いことに気づき、古い顧客をすべて新しい西門店に引き寄せたいと考え、東門麻辣湯
店
は入口の道路工事の影響で食事環境が良くないので再度お知らせします 今後麻辣湯を食べたい場合は西門に直接行ったほうが良いです この店舗はもう営業しておりません
この時点では、あなたと友達はいつものように麻辣湯を食べるために東門に来ますが、通知を見つけた後は西門に行かなければなりません。しばらくすると、あなたと友達は直接西門に行き
ます麻辣湯を食べに
（一度リダイレクトした後、次回は新しい場所に行きます）
この動作は永続的なリダイレクトと呼ばれ、
永続的なリダイレクトではブラウザのローカル ブックマークが変更されます。
一時的なリダイレクト (302) であっても永続的なリダイレクト (301) であっても、新しいアドレスが東門馬羅桞店に残され、クライアントはステータス コード 301 302 307 に場所を加えたものを返すことがわかります。場所別。新しい店舗の住所を追跡できます
場所: 3xx ステータス コードとともに使用され、クライアントに次に訪問する場所を伝えます。
一時的なリダイレクトが実行中
Main.cc の HandlerHttp コールバック関数では、
ユーザーがリクエストを送信している限り、直接リダイレクトされます。
文字列応答を定義し、それに 302 (一時リダイレクト) を追加してhttps://www.qq.com/に
リダイレクトします。
ホストIP + ポート番号を入力すると、qq公式Webサイトに直接ジャンプします。
永続的なリダイレクトの実践
文字列応答を定義し、それに 301 (永続リダイレクト) を追加してhttps://www.baidu.com/に
リダイレクトします。
ホスト IP とポート番号を入力すると、Baidu の公式 Web サイトに直接ジャンプします。
コードをコメントアウトし、実行可能プログラムを実行し、ホスト IP+8888 を入力しても、Baidu の公式 Web サイトのままです。
4.HTTPセッション永続化機能について
HTTP 自体はステートレスです。
たとえば、file1 にアクセスした後、しばらくしてからも file1 にアクセスしたいと考えた場合、HTTP は file1 が少し前にアクセスされたことを認識せず、引き続きリクエストを作成します。
サイト B を開いてユーザーにログインした後、サイト B を再度開くと、ユーザーはすでにログインしていることがわかりました。そのため、Cookie とセッション
Cookieが必要です。クライアントに少量の情報を保存するために使用され、通常は次の目的で使用されます。セッション機能を実装します。
ログインすると、サーバーはいくつかの Http オプションをローカル ブラウザに渡し、いくつかの Cookie 情報をローカルに書き込む
ため、サイト B に再アクセスするとき、ユーザーはすでにログインしていることになります。
サイト B に対応する Cookie を削除し、再度サイト B に入ると、再度ログインする必要があります。
クッキーの使用
サーバーには多くのリソースがあります。
特定のリソースをリクエストするとき、サーバーはログインがないことを検出すると、クライアントにログインを要求します。
アカウントとパスワードを入力すると、サーバーはアカウントとパスワードを認証します
。認証に合格すると、認証が成功したことが返されます。
サーバーは Set-Cookie を通じて個人情報 (ユーザー名、パスワードなど) を HTTP 応答に組み込みます。
ブラウザは Cookie を含む情報を受信すると、応答内の Cookie 情報をローカルに保存します。
ブラウザには 2 つのローカル ストレージ ソリューションがあります。 . : メモリレベル、ファイルレベル
今後同じ Web サイトにアクセスするたびに、リクエストには
自動 ID 認証のための Cookie 情報 (ブラウザによって自動的に行われます) が含まれるため、ユーザーはアカウントとパスワードを入力する必要がありません。
ハッカーが送信した不適切なリンクをクリックすると、ハッカーはすべての Cookie 情報を盗み、
あなたが訪問した Web サイトにもハッカーがアクセスした場合、その Web サイトにログインしているユーザーは依然としてあなたです。
セッションIDの提案
以前のソリューションには明らかな欠点があり、ハッカーが対応するアカウントのパスワードやその他の情報を入手できるため、
現在のソリューションを使用してください。
現在のサーバーには多数のリソースが存在します。
特定のリソースをリクエストする際、サーバーがログインがないことを検出すると、クライアントにログインを要求します。
ログインするときは、POST メソッドを使用してアカウントとパスワードを入力する必要があります。アカウントとパスワードを入力する
と、サーバーはアカウントとパスワードを認証します。
認証に合格すると、新しいソリューションは、サーバー上にセッション オブジェクトを形成します。サーバー(現在のユーザーの基本情報が入力されます)、
セッションID (10/16 の 16 進数で形成されたシーケンスは一意であることが保証されています) は、
http 応答を通じてクライアントにセッション ID を渡します。
後でアクセスする場合、HTTP リクエストにはセッション ID が含まれるため、セッション ID を使用してセッション ID が存在するかどうかを確認し、存在する場合はリソースにアクセスできます。
ハッカーが再び情報を盗んだとしても、セッション ID のみが盗まれるだけであり、リソースへのアクセスには引き続き ID が使用されますが
、ユーザーのアカウントとパスワードが漏洩する心配はありません。