HTTPヘッダを見るシリーズ第3弾はGoogle。気になるヘッダをMDN Web docsやグーグル先生で調べていく。

ヘッダ全体

$ curl -XGET -I https://www.google.com
HTTP/2 200
date: Wed, 04 Nov 2020 14:35:29 GMT
expires: -1
cache-control: private, max-age=0
content-type: text/html; charset=ISO-8859-1
p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
server: gws
x-xss-protection: 0
x-frame-options: SAMEORIGIN
set-cookie: 1P_JAR=2020-11-04-14; expires=Fri, 04-Dec-2020 14:35:29 GMT; path=/; domain=.google.com; Secure
set-cookie: NID=204=XXXX; expires=Thu, 06-May-2021 14:35:29 GMT; path=/; domain=.google.com; HttpOnly
alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
accept-ranges: none
vary: Accept-Encoding

Expires

expires: -1

Expiresで有効期限切れにする方法は、過去の日付の指定以外に、無効な日付であっても成立する。0でもよいはずだが-1を指定していた。

Cache-Control

cache-control: private, max-age=0

privateな情報を扱うため、プロキシなどの共有キャッシュには残してはいけないが、個人のブラウザのキャッシュには残しても良い。ただし、max-age=0なため即座に有効期限切れになり、ブラウザは毎回サーバにキャッシュが古くないかIf-Modified-Sinceヘッダをつけてリクエストを飛ばす（検証する）必要がある。という意味。もし古くなってなければ304 Not Modifiedレスポンスが返ってきて、キャッシュを使うことができる。

個人のブラウザのキャッシュすら禁止したい場合はno-storeを使う。

Content-Type

content-type: text/html; charset=ISO-8859-1

curlで取得するとcharsetがISO-8859-1（ラテン語）になる。chromeで確かめるとISO-8859-1ではなくutf-8が使われていた（？）

f:id:dorapon2000:20201105013017p:plain

いろいろ試した結果、User-AgentヘッダをChromeのものにしたらcharsetがutf-8になった。

$ curl -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" -XGET -I https://www.google.com
HTTP/2 200
content-type: text/html; charset=UTF-8

GoogleはUser-Agentでcharsetを変えるらしい。

P3P

p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."

P3PはPlatform for Privacy Preferencesのことで、そのサイトがユーザーの個人情報をどう扱うかを表明したもの、とのこと。facebookの説明によると、現在は形骸化しているらしい。おそらくP3Pに記述されたポリシーに従って、ブラウザがサイトを拒否したりしなかったりする未来を考えていたのだと思う。CPはコンパクトポリシーの略で本来であれば特定のポリシーを表す略語が入るが、GoogleはP3Pへのリンクを貼っている。

P3PはW3C (World Wide Web Consortium)が策定した標準規格ですが、最新のウェブブラウザーのほとんどがP3Pを完全にはサポートしなくなったため、この標準化作業は数年前に中断されました。その結果、P3Pは時代遅れの規格となり、ウェブで現在使われている技術を反映していないため、ほとんどのウェブサイトがP3Pポリシーを採用していないのが現状です。

FacebookにおけるPSP (Platform for Privacy Preferences)の利用 | Facebookヘルプセンター | Facebook

Alt-Svc

alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"

GoogleはHTTP/3を導入しているため、h3で接続してもいいとAlt-Svcでブラウザに伝えている。

Accept-Ranges

accept-ranges: none

「ファイルの一部だけ取得する」ということができないことを表す。一部だけ取得するの意味がわかりづらいので、取得できる場合をコマンドで確認すると以下のようになる。

$ curl https://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"
HTTP/2 206
content-type: image/jpeg
accept-ranges: bytes
content-range: bytes 0-1023/146515

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

$ curl https://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023" --output pic.jpg

$ file pic.jpg
pic.jpg: data

画像の先頭1014バイトだけ取得している。ステータスコードの206はPartial Contentで部分的なファイルのレスポンスを表す。なお、中途半端なのでファイルに落とし込んだとしても壊れて開けない。用途として、ファイルダウンロードを中断後にサーバが対応していればAccept-Rangesによって再開できる。

Googleのヘッダの話に戻り、Accept-Rangesがなければnoneと同じ意味になるが、Googleはあえて明示しているようだ。

まとめ

p3pというおもしろいヘッダと出会えたし、ファイルダウンロードの再開の仕組みもわかった。また、過去の調べたTwitterとFacebookとの共通点はx-xss-protection: 0であること。XSSの予防につながるのだから1で良い気がするが、なぜどこも0なのだろうか。こういう気づきも面白い。