Open frankhinek opened 6 months ago
For did:dht
, the proposed impelementation does:
notFound
, when the given did isn't found by the gateway.internalError
for all other types of errors, e.g. a timeout.@andresuribe87 Given that, what are your thoughts on returning internalError
in the event the HTTP GET request during resolution of a did:web
DID either outright fails (network transport layer issue) or returns a status code other than 200?
@frankhinek I proposed something a bit different in this PR:
notFound
internalError
. For example, timeouts or parsing errors.The motivation behind this was to follow the did spec notFound definition (which was pointed by you at the top).
FWIW, this reference implementation always returns notFound
when there are any issues.
Seeking commentary on what the
resolve()
function in our DID method/resolver implementations should do when there is either a network failure or upstream gateway failure. Examples include:did:web
, when attempting a GET to the server specified by the DID URI the network call might return a failure or the remote server could respond with status codes 404, 500, 503, etc.did:dht
, there are multiple steps in the resolution process where network calls or upstream gateways might return an error statusWe haven't yet added test vectors for DID DHT but there is one test for DID Web checks for
didResolutionMetadata
containing an error value ofnotFound
given an invalid domain.Do we want to mirror this pattern for other DID test vectors? Should implementations raise an exception? (Kotlin/JS) or return an error result (Go, Rust). Is it up to the implementation and all of the Web5 SDKs will do it differently?
Additional Reference Information