Webクライアント

先に尋ねるほうがクライアントです

クライアントとサーバーは機械ではなく役割です。先に話しかけて何かを求めるほうがクライアント、待って答えるほうがサーバーです。ブラウザーもクライアント、curlもクライアント、スマホアプリも、APIを呼ぶ別のサーバーもクライアントです。

だからWebクライアントは一行で書けます。窓も、描画エンジンも、マウスも要りません — つなぎ、リクエストを送り、返ってきたものを読めばよいのです。

ターミナルでWebクライアントを作る

HTTPが文字にすぎないといちばん早く納得する方法は、リクエストを自分で打つことです。前のテーマのシェルWebサーバーを立てておき、ターミナルをもう一つ開いて手で話しかけてみてください。

ncでリクエストを手書きする

netcatはポートにつなぎ、打った文字をそのまま線へ流します。二行打ってEnterを二度押せばサーバーが答えます — 今あなたはブラウザーの仕事を手でやりました。

# connect, then type the two lines below and press Enter once more
nc localhost 8084

GET / HTTP/1.1
Host: localhost

# or send it all at once (printf's \r\n is HTTP's line break;
# sleep keeps the line open a moment so the shell server can answer)
{ printf 'GET / HTTP/1.1\r\nHost: localhost\r\n\r\n'; sleep 1; } | nc localhost 8084

• 最後の空行が大事です。リクエストが終わったとサーバーに告げる印で、だからEnterをもう一度押します。
• HTTPは行末ごとにキャリッジリターンと改行を求めます。手打ちでも通るのは多くのサーバーが寛容だからで、printf版は規格が求めるとおりを送ります。
• Hostの行はHTTP/1.1が必ず求めます。本物のサイトへこれなしで送ると、ページではなくエラーが返るのがふつうです。

スクリプトに包む

リクエストがprintf一行になれば、使い回せるクライアントは数行で済みます。下のスクリプトはホスト・ポート・パスを受け取ってリクエストを送り、ヘッダーと本文を分けて見せます。

#!/bin/bash
# usage: bash client.sh localhost 8084 /

HOST=${1:-localhost}
PORT=${2:-8084}
PATH_=${3:-/}

{ printf 'GET %s HTTP/1.1\r\nHost: %s\r\nConnection: close\r\n\r\n' "$PATH_" "$HOST"; sleep 1; } \
  | nc "$HOST" "$PORT" \
  | tr -d '\r' \
  | awk 'BODY { print; next } /^$/ { BODY = 1; next } { print "[header] " $0 }'

trはHTTPが行末ごとに残すキャリッジリターンを取り除き、awkは空行に出会うまでをヘッダーとして印を付けます — その後はすべて本文です。ブラウザーが描き始める前にする分け方とまったく同じです。

curl — 毎日使うことになるクライアント

こちらのスクリプトが大ざっぱにやっていたことを、curlはきちんとやります。リダイレクト、HTTPS、ヘッダー、アップロード、時間切れ、クッキーまで。ほとんどの機械に入っていて、ブラウザーを挟まずにサーバーを確かめる標準の手段です。

# body only
curl http://localhost:8084

# body plus the response headers
curl -i http://localhost:8084

# the whole exchange, request headers included
curl -v http://localhost:8084

大事なオプション

APIを呼ぶ

今どきのアプリが話す相手は、ページではなくJSONを返すAPIであることが多いものです。curlがそれを取り、jqが読みやすく整えます。アプリのコードを一行も書かないうちにエンドポイントを確かめる方法です。

# fetch JSON and pick one field out of it with jq
curl -s https://api.github.com/repos/sveltejs/svelte | jq '.stargazers_count'

# send JSON with POST
curl -X POST https://httpbin.org/post \
  -H 'Content-Type: application/json' \
  -d '{"name":"SONUB","level":1}'

# download to a file
curl -L -o page.html https://sonub.com

何であれ、まずcurlで試す癖を付けてください。curlが正しい答えを受け取れば、サーバーは無事で、間違いは自分のプログラムにあります。curlも変な答えを受け取るなら、問題はサーバー側です。見当違いの場所を半日探さずに済みます。

Chromeも同じクライアント、大きさが違うだけ

Chromeは、あなたがncで送ったそのリクエストを送ります。そのあと、返ってきた答えを人が見られる画面に変える途方もない仕事を足します — 本当の違いはその「足し」だけです。

その段取りを知っておく価値があります。一つひとつがページの狂う場所だからです。何かが出てこないとき問うべきは、いつでも「どの段階で失敗したのか」です。

アドレス欄から絵まで

1. 名前を解くDNSがドメイン名をIPアドレスに変えます。ここで失敗するとサーバーに届きもせず、エラーもページではなく名前を指します。
2. つないで安全にする接続を開き、httpsなら何かを送る前に証明書を確かめます。ここで出る警告はページがないという意味ではなく、暗号を信用できないという意味です。
3. リクエストを送るあなたが手で打ったのと同じ数行に、ヘッダーがずっと多く付きます。クッキー、読める形式、好みの言語などです。
4. 解釈して残りを取りに行くHTMLを読み、タグから要素の木を組み立てます。そして、ページが指すものをすべて要求します。スタイルシート、画像、フォント、スクリプトは、たいてい同時に何本も届きます。
5. 飾り、並べ、描くCSSを当て、箱ごとの位置を計算して描きます。JavaScriptはHTMLを読んでいる途中でも動き、描いたあとにも画面をまた書き換えられます。

ターミナルのクライアントか、ブラウザーか

開発者ツール — 行き交う文章を目で見る

ChromeにはWebのデバッグ道具が備わっていて、もう入っています。ncで手ずから送っていたものが、ここではリクエスト一件ずつ、隣にレスポンスも添えて並びます。

パネル

いますぐ試す三つ

1. 自分のリクエストを探すNetworkパネルを開いてこのページを再読み込みし、いちばん最初の項目を押してください。そこにあるリクエストとレスポンスのヘッダーは、ncに打ち込んでいた行と同じ内容です。HTTP/2でつながるサイトでは、最初の行とHostが:method・:path・:authorityという名前で見えます。
2. curlとしてコピーするリクエストを右クリックして[Copy as cURL]を選び、ターミナルに貼り付けてください。ヘッダーもクッキーもそのまま、ブラウザーがした通りを再現したことになります。
3. わざと壊してみるElementsパネルで見出しを消して消えるのを見て、Networkで速度を遅く絞ってから再読み込みしてみてください。どちらも安全で、どちらも読むより多くを教えてくれます。