12
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

【HTTP】Chromeデベッロッパツール のHTTPヘッダの解説

Posted at

#HTTPとは
簡単に説明するとクライアントとサーバーの通信方法みたいなものです。

URLが入力されるとまずは、DNSサーバーと言うサーバーに問い合わせされます。
このDNS(DomainNameSystem)サーバーと言うのはURLをIPアドレスに変換してくれる場所です。
と言うのもURLだけじゃアルファベットの羅列だけなので、どこに何があるかわからないんですね。
なので、インターネット上の住所となるIPアドレスと言うものに変換してもらう必要があるのです。

1,URLをアドレスバーに入力
2,DNSサーバーに接続
3,DNSサーバーがURLをIPアドレスに変換
4,IPアドレスがクライアントに返される
ここまではこんな流れです。

それ以降もまだやりとりが続きます。
今はまだ、このURLはこの住所(IPアドレス)にありますよと言うことが判明しただけです。

次はこのIPアドレスのデータを取得しにいかないといけません。
そのときに接続されるのがWebサーバーです。
Webサーバーには「このIPアドレスのデータを頂戴!」と送信します。
それがHTTPリクエストです。

そのHTTPリクエストが届くとサーバーはこのリクエストを解析しリクエスト通りのファイルを送り返します。
これをHTTPレスポンスと言います。

レスポンスされたデータをもとにクライアントは閲覧者に見える形にしてブラウザに表示させます。
では実際にどんな情報がやり取りされているのか見てみましょう。
##General
まずはGeneralから。
スクリーンショット 2019-04-11 19.43.17.png
上から
Request URL・・・そのまんまですね。リクエストしたURLです。
Request Method・・・通信鳳凰ですね。googleから検索したのでGETになっています
Status COde・・・HTTPリクエストというものです。200なら成功。ちなみに404はサーバーにページがないという状況です。
Remote Address・・・IPアドレスです。上述した通りDNSサーバーへURLが送られるとURLはIPアドレスに変換され返されます。
Referrer Policy・・・Referrerを表示するかしないかを設定しています。ちなみに「no-referrer-when-downgrade」はhttpsからhttpに飛んだ場合はセキュリティ上表示しませんよ、という設定です。リンク先がSSL化されていないのに、HTTPクエリに漏れてはいけない暗号や値が入っていたら大変のことです。

##Request
次はRequestです。
スクリーンショット 2019-04-12 18.59.52.png
上から

authority・・・権限です。そのまんまですね。このリクエストの権限はfeelshare.jpが持っていますという意味。
method・・・通信方法です。
path・・・これも見ての通りパスです。
scheme・・・スキーム。
accept・・・和訳は「受け入れ」です。text/htmlなどを受け入れることができますという意味。
accept-encoding・・・圧縮アルゴリズム。サーバーとのやりとりを軽くするためにデータを圧縮してやりとりをしています。その際解凍できない圧縮方法でレスポンスされても困るので、Accept-Encodingで圧縮方法を指定してあげます。簡単に言うと「この方法なら解凍できるよ」と言ったものです。
accept-language・・・そのまんまんですね。受け入れることができる文字種です。
cookie・・・クッキー。
referer・・・どのページから飛んできたのかを表示しています。
upgrade-insecure-requests・・・コード内にhttp://を含リンクがあればhttps://として扱ってくださいというもの。
user-agent・・・使用している機種。

##Response
お次はレスポンスです。
スクリーンショット 2019-04-14 12.51.59.png
上から
cache-controrl・・・キャッシュコントロール。キャッシュにはブラウザキャッシュとキャッシュサーバーの2つがあり、基本的にはサーバー側で処理します。そのキャッシュをどうするのかと言う設定です。no-storeは「全てのキャッシュを行わない」です。PHPなどを使って動的に処理する必要がある場合に設定します。no-cache「有効なキャッシュか確認が取れない限り使わない」と言う設定です。この確認は本来のwebサーバーへ確認します。 must-revalidate「キャッシュが有効か否か必ず問い合わせろ」と言う設定です。
content-encoding・・・データの圧縮方法ですね。上述したaccept-encodingで「gzipという方法なら解凍できるよ」とリクエストを送っています。なのでサーバーはgzipという方法でデータを圧縮しています。
content-type・・・レスポンスしたファイル形式と文字コードです。
date・・・日付。
expires・・・キャッシュの有効期限。推奨は一週間から一年。過去の日付になっている場合は0秒と判断する。
pragma・・・HTTP1.0の下位互換です。cache-controrlとやっていることは似ています。
server・・・サーバー名
set-cookie・・・セッションIDとexpires。つまりセッションIDの有効期限です。
status・・・HTTPステータス。200は通信成功。
vary・・・キャッシュサーバーに残っているキャッシュのUser-Agentやaccept-encodingのデータとリクエストされたUser-Agentやaccept-encodingが違っていた場合、キャッシュを更新するためのヘッダー。(多分・・・間違っていたら教えてください。)

###外伝
content-typeで気になったものがあったので調べました。

##application/x-www-form-urlencoded; charset=UTF-8
Ajaxの非同期通信をさせていた時にhttpリクエストにapplication/x-www-form-urlencoded; charset=UTF-8が出てきたのでまとめます。

##そもそもなんなの?
application/x-www-form-urlencoded; charset=UTF-8を結果から言うとformからクライアントがサーバーに送信するときのcontentTypedです。

ちなみにformがひとつ増えるたびにform1=data1&form2=data2と増えていきます。

##contentTypeって何?
ファイル形式みたいなものです。
「今送信したものはformタイプのファイルだよー」と言った具合です。
これがtext/htmlってなってたら「htmlファイルを送るよー」と言う感じになります。

クライアント(ブラウザ)はサーバに「このURLの情報を持ったファイルを頂戴!」とデータを送ります。このことをHTTPリクエストと言います。

##まとめ
以上がHTTPヘッダの解説です。

尚、どこか間違っているところや「こんな側面もあるから覚えておいた方がいいよ」ということがあれば是非教えてください!

12
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?