洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to julian

@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.

w3id.org

Cookie monster!

2 replies

silverpill
@silverpill@mitra.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@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

rfc-editor.org

RFC 9421: HTTP Message Signatures

This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.

julian
@julian@activitypub.space · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@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

developer.mozilla.org

426 Upgrade Required - HTTP | MDN

The HTTP 426 Upgrade Required client error response status code indicates that the server refused to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.