何年も前のことだけど、PLSQLサーバーページのバージョンがあって、知らないクエリ文字列を渡そうとすると500を返してた気がする。

「414 URIが長すぎるって言われてるかもしれないけど、こういう方が面白いと思う。他に考えた選択肢は、400 Bad Request、一般的なクライアントエラーコードで、正しいけどつまらない；402 Payment Required、正直言って、特定のURLをクエリ文字列付きで動かすためにお金を払ってくれるなら、全然OK；404 Not Found、でも副作用が出やすいし、リクエストが不正だったっていうアイデアを伝えられないから、これも違う；303 See OtherでLocationヘッダーなし、最近ではかなり珍しいけど、正当なものだ。RFC 2616では「異なるURIはレスポンスのLocationフィールドで示されるべき」と書かれてたけど、7231と9110ではLocationヘッダーの存在を前提にした言い回しになってるんだよね（「…LocationヘッダーフィールドのURIで示される」）、301、302、307、308は「サーバーはLocationヘッダーフィールドを生成すべき」とも言ってる。まあ、LocationヘッダーなしのSee Otherは妥当だと思うけど、URIが長すぎるのは面白かった。」 https://chrismorgan.info/no-query-strings?foo

パスとクエリ文字列の違いが完全に恣意的で、サーバーによって決まっているって気づくまで待ってみて。クエリ文字列なんて存在するべきじゃなかった。CGIウェブサーバーの実装の詳細があちこちに漏れ出して、今じゃ本当に臭くなってる。

昔はCMSやフォーラムがindex.phpだけで、クエリ文字列でルーティングするのが普通だったよね（フォームURLエンコード形式で、みんな野蛮人じゃなかったし）。だから、index.php?p=homeとかindex.php?p=shopとかあったり。あるいはindex.php?action=showthread&forum=42&thread=17976みたいな感じ。そういう仕組みだと、未知のクエリパラメータに対して404が正しい答えだってすぐにわかるはず。実際、今でもそういうサイトはたくさんあって、SEOのためにapache/nginxのリライトルールの裏に隠してるだけなんだよね。

面白いことに、クエリ文字列を透明に扱うべきところが、その構造についてたくさんの仮定をしていることがあるよね。新しいCDNを選ぶときにそれにぶつかったんだけど、いくつかのプロバイダーは繰り返しのパラメータ（?a=1&a=2）を正しく処理できなかったんだ。

ああ、いくつか理由があるよ。ユーザーたちは追跡されることに同意していない（これらのクエリパラメータは追跡情報だから）、サイト管理者は受信トラフィックを追跡されたくないんだ。後者は理解しにくいかもしれないけど、例えば、ユーザーに害を及ぼす可能性のある情報がログに残るのは絶対に避けたい。個人的には、メッセージで送るためにリンクをコピーしようとしたとき、追跡コードが元のURLの2倍の長さになってるのが嫌なんだよね…それを整理するために手間をかけるか、送った相手にランダムな文字のスクリーンを見せて「何これ？」って思わせるかのどっちかになるから…だから、ユーザーのプライバシーを侵害してるし、クソなUXだし、そもそも誰もそれを求めてないんだよね…

これに関する人々の問題を知りたいなら、http refererヘッダーについて調べてみてね：https://en.wikipedia.org/wiki/HTTP_referer どんな理由であれ、サイトに自分がどこから来たかを知られたくないことがある。基本的に、訪問しているサイトに自分のブラウジング履歴を共有しているようなものだから。このため、http refererヘッダーには多くの更新があり、送信されるタイミングに制限があったり、機能から完全にオプトアウトできるようになっている。これらの既存のルールやオプトアウトの能力を回避するために、同じ情報を持つURLパラメータを追加するのは良くない。標準を使うべきだよ。

面白いのは、これらのサイトには「検索」機能がないことだね。これは重要なアクセシビリティ機能で、クエリ文字列の明確で正当な使用ケースだと思う。