Closed jernst closed 1 month ago
- This is probably what a good library would do, so that the code invoking the library could report errors nicely.
I don't think that most Fediverse WebFinger implementations are built as a library (based on the code I've observed). I'd expect that they will typically raise an exception or implement some app-specific handling if a WebFinger response is invalid for some reason that's significant to that specific app. Some invalid responses will be commonly accepted in non-fixture clients. For example, I'd guess that most apps accept application/json
as a content type for WebFinger responses. I'd guess the same for extra nonstandard keys in the WebFinger JRD.
EDIT: Just to be clear, I think this is a reasonable approach for the "Imp" given its role.
Changing the WebFingerClient API slightly: Instead of throwing an Exception the first time the an implementing class doesn't like something, don't throw but return a set of all problems. This is probably what a good library would do, so that the code invoking the library could report errors nicely. It allows us to filter out certain errors when running certain tests, so that the errors reported in a given test actually match what the test is trying to test.
Better and more consistent error reporting
Fix incorrect ClaimedJrd recursive comparison
Fix the Imp API to match the WebFingerClient API (has consequences for the actual tests)