@julian That's a fair point; honestly, right now there's no reliable way to know. If a server supports both RFC 9421 and draft cavage, and you lead with cavage, you can't infer anything about its RFC 9421 support from a successful response.

The workaround I applied is intentionally temporary, just to keep things working while Bonfire instances catch up with the fix. Once they do, I'll revert firstKnock back to RFC 9421.

The longer-term answer to your question might be FEP-844e, which proposes a capability discovery mechanism—servers could explicitly advertise which specifications they implement (including RFC 9421) via an Application object. That would make the guesswork unnecessary. It's still a draft, but worth keeping an eye on.

@hongminhee @julian

>you can't infer anything about its RFC 9421 support from a successful response

In theory, a server that implements RFC-9421 may add Accept-Signature header to the response

@hongminhee@hollo.social ah yes, implements would be a good thing to support. It would allow you to cache the value temporarily (maybe a quick recheck every 7 days or so) so as to avoid needing a double knock at all.

Caching based on first knock success also works.

I wonder if sending HTTP 426 is doable too... 🤔

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/426