RFC 7033 - WebFinger
https://datatracker.ietf.org/doc/html/rfc7033#section-4.2
> A WebFinger resource MAY redirect the client; if it does, the redirection MUST only be to an "https" URI and the client MUST perform certificate validation again when redirected.
リダイレクト時に証明書の検証をしろとわざわざ要求しているの、ひいき目に見てもWebFingerプロトコルの領分ではないし、接続の再利用などを考えると実際のところ怪しい記述な気がするのだよなあ
他にも4.1.節ではリクエストのURLのクエリ部分を作る方法について、パラメタの名前と値をパーセントエンコードして`=`でつなげてさらにパラメタ間を`&`でつなげて……などと1段落かけて`x-www-form-urlencoded`の再発明をしているし（これに関してはWHATWGのURL Standardへの参照を避けたいからとか？）、4.2.節ではエラーの場合においてもnon-secureなHTTPで再試行してはならない（MUST）などと要求している（TLSへの執着が激しいな）
それでいて、JRD文書の`subject`がリクエストの`resource`と異なる場合にクライアントが行うべき処理のような重要なケースについての記述が抜けているという。この場合は新たな`subject`を`resource`としてWebFingerクエリを再試行するのが一般的なのだけど、それはあくまで実装が気を利かせて勝手にやっているだけであって、規格として定められたわけではないっぽいのが困りどころである（これが規格に明記されていたら`subject`をカノニカル化しない実装に対してその旨を堂々と指摘できて話が楽だっただろうに）
こうしてMisskeyユーザは`threads.net`の代わりに`www.threads.net'を目にすることになったというわけです（？）
QT: https://fedibird.com/@tesaguri/111646377615491667 [参照]
まあMisskeyについては<https://github.com/misskey-dev/misskey/issues/7922>の"wontfix"ラベルが外されているから、対応する気がないわけではないのだろうけど
WebFingerのクライアントライブラリみたいなのはないこともないけど、少なくとも私が探した時点ではどれもリソースを取得してJRDをデシリアライズする薄いラッパといった感じで、このあたりの処理を扱っているものはなかったと記憶している。まあ難しい処理でもないから必要なら自分で書けば良いわけだけど（一応多少のセキュリティ上の配慮が求められる処理ではあるけど）
（いや、その多少のセキュリティ上の配慮のせいで真面目にやろうとするとそこそこのテストコードが必要になるわけだけど）
