「長い感想を入れると、保存できないんです」。
お客様の声を管理画面から登録する機能で、そう報告を受けた。短い文章なら通る。けれど、改行や絵文字の入った長めの文章を、何件かまとめて保存しようとすると、「通信エラー」になる。
「Expecting value」という謎のエラー
ログを見ると、サーバーからの応答が、こう言っていた。「Expecting value」。値が期待される、という意味だ。
最初は意味が分からなかった。保存のリクエストを送って、返ってきた応答を読もうとしたら、それが想定していた形——構造化されたデータ——ではなかった。だから「値があるはずの場所に、値がない」と怒られていた。
つまり、サーバーは正常な応答を返せていなかった。問題は、送る側にあった。
URLに、データを載せていた
原因は、送り方だった。
保存するデータを、リクエストのURLに載せて送っていたのだ。短い文章なら、URLは短い。けれど、長文・改行・絵文字・複数件となると、URLがどんどん伸びる。そしてURLには、長さの上限がある。上限を超えたところで、リクエストは途中で壊れる。サーバーは正しい応答を返せず、受け取った側が「Expecting value」とつまずく。
データの中身は、何も悪くない。ただ、運び方が間違っていた。
大きい荷物は、本文で送る
直し方は、運び方を変えることだった。
URLに載せるのではなく、リクエストの本文に入れて送る。URLは住所を書くところで、本文は荷物を入れるところだ。大きい荷物を住所欄に書こうとするから、あふれていた。本文に移したら、長文も改行も絵文字も、何件でも通るようになった。
上限は、超えるまで見えない
厄介だったのは、ふだんは何ともなかったことだ。
短い文章でテストしている間は、URLは上限に届かない。だから問題なく動く。動いてしまうから、誰も気づかない。上限は、超えた瞬間に初めて姿を現す。そしてそれは、たいてい本番で、長い文章を入れた誰かが最初に踏む。
「自分のテストでは通った」は、安心の理由にならない。テストが軽すぎただけかもしれない。だから今は、限界が決まっているもの——URLの長さ、ファイルの大きさ、件数——には、わざと大きい値を一度通してみる。普通の使い方では見えない壁を、自分で先に叩いておく。
エラーメッセージは、犯人ではない
この件で学んだのは、エラーメッセージの読み方だ。
「Expecting value」は、応答を読む側が出したエラーだった。だから最初、読む側を疑った。でも本当の原因は、その手前——送る側がURLに載せすぎて、応答そのものが壊れていたことにあった。
エラーが出た場所と、原因がある場所は、よくずれる。表に出たメッセージは、たいてい犯人ではなく、被害者だ。だからエラー文をそのまま検索する前に、「これは誰が、どの段階で出したエラーか」を一度たどるようにしている。