はじめに
特定のURLのみクエリを追加する処理を実装したのですが、意外に考慮することが多かったのでまとめました。
の箇所は 私の個人的見解です 。
処理内容
例として、https://example.com
というURLにアクセスする場合のみ example=1
というクエリを追加する処理を実装することにします。
URL比較の考慮事項
特定のURLかどうか判定するために考慮すべき内容です。
大文字・小文字を区別するか
大文字と小文字が異なる場合に同一のURLとみなすかどうかです。
大文字・小文字を区別せず、同一のURLとみなします。
∵大文字・小文字が異なっても同一のページにアクセスされるため
末尾スラッシュの有無を区別するか
末尾にスラッシュ /
が付いている場合に同一のURLとみなすかどうかです。
基本的には末尾にスラッシュがあるか異なっても、同一のURLとみなします。
∵ 大文字・小文字と同様、同一のページにアクセスされるため
→Webサイトによっては異なるページにアクセスされる可能性も0ではありませんでした。
ただ、基本的には同一のページにアクセスされるようにしているWebサイトがほとんどです。
同一ドメインでページが異なるのを区別するか
こちらはクエリを追加する状況によりますが、基本的には異なるURLとみなします。
∵異なるページにアクセスされるため
異なるURLとみなす場合、ドメインだけで判断しないよう注意が必要です。
クエリを除いて判定するか
例
https://example.com?foo=1&bar=2
クエリの内容が異なっても同一とみなすかは、クエリを追加する状況によります。
比較に手間がかかるため、問題なければ異なるURLとみなします。
同一のURLとみなす場合、対象クエリがすでに追加されていないか注意が必要です。
ページ内リンクを除いて判定するか
ページ内リンクが異なっても同一とみなすかは、クエリを追加する状況によります。
比較に手間がかかるため、問題なければ異なるURLとみなします。
プロトコルを区別するか
HTTP or HTTPSとプロトコルが異なっても同一とみなすかは、クエリを追加する状況によります。
比較に手間がかかるため、問題なければ異なるURLとみなします。
クエリ追加の考慮事項
URLが一致と判断したあと、クエリを追加する場合に考慮すべき内容です。
他にクエリが付いている
例
https://example.com?foo=1&bar=2
文字列ベースでクエリを追加すると、先頭に ?
と &
のどちらを付けるかの判定に手間がかかります。
言語仕様でURLオブジェクトにクエリを追加する処理がある場合、そちらを活用すべきです。
すでに対象クエリが付いている
例
https://example.com?example=1
まず、クエリの大文字・小文字が異なっても、同一クエリとみなします。
上書きするかそのままにするかは、クエリを追加する状況によります。
クエリを上書きする場合、同じクエリを複数追加しないよう注意が必要です。
対象クエリに追加する値に問題がある
対象クエリに追加する値が存在しない、または不整合がある場合、どうするかは状況によります。
クエリを追加せずにそのままURLにアクセスするか、エラーを発生させるかのどちらかが考えられます。
まとめ
上記の内容を表にまとめました。
URL比較の考慮事項
説明 | URLの例 |
---|---|
通常 | https://example.com |
大文字が混ざっている | https://Example.com |
末尾に / が付いている |
https://example.com/ |
同一ドメインでページが異なる | https://example.com/test |
クエリが付いている | https://example.com?foo=1&bar=2 |
ページ内リンクが付いている | https://example.com#test |
HTTPプロトコルになっている | http://example.com |
クエリ追加の考慮事項
説明 | URLの例 |
---|---|
他にクエリが付いている | https://example.com?foo=1&bar=2 |
すでに対象クエリが付いている | https://example.com?example=1 |
対象クエリに追加する値に問題がある | - |
おわりに
URLを細かく扱ったことはなかったので、考慮事項の洗い出しに苦戦しました。
他にも考慮すべき内容がありましたら、コメントなどでご指摘いただけると嬉しいです