KeyError key not found: "url"
jeromegn opened this issue · comments
I started noticing this error while trying out the latest 2.0.0 version:
gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:58:in `fetch': key not found: "url" (KeyError)
from gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:58:in `initialize_challenge'
from gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:23:in `block in challenges'
from gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:22:in `map'
from gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:22:in `challenges'
from gems/acme-client-2.0.0/lib/acme/client/resources/authorization.rb:28:in `http01'
...
It seems odd the other keys would be found, but not this one. This error has been happening quite a few times and it's always that specific key. Can't be a coincidence!
@jeromegn
Can you provide code snippet and some more info to help me understand where the problem lies?
Good question. It's hard to say because this is a very automated process. We request a lot of authorizations, challenges and new orders at Fly.io
It happens only very rarely when trying to get an http challenge. I suspect the Let's Encrypt API returns an irregular response in some cases?
It's always the url property. Maybe there's a condition where the challenge would not return a URL.
It's always the url property. Maybe there's a condition where the challenge would not return a URL.
@jeromegn Do you have examples of the challenge URLs that were fetched when the missing url property error occurs?
@unixcharles Does acme-client log the response body from a GET to a challenge resource anywhere that could be looked at after the fact?
Oh, my bad. I used a v1 URL. Must have had bad logic somewhere. I refactored this thing a lot. I wonder if acme-client should care if it's a v1 URL (raise an exception, or support it.)
Oh, my bad. I used a v1 URL. Must have had bad logic somewhere. I refactored this thing a lot. I wonder if acme-client should care if it's a v1 URL (raise an exception, or support it.)
Aha! That was the only theory I had about why only the url field would be missing. The ACME draft specification changed the challenge resource field name from "uri" in early ACME v1 days to "url" in the current drafts. If you fetch an authorization through the ACME v1 API it will have a "uri" and no "url", if you fetch the authorization through the ACME v2 API it will have a "url" and no "uri".
The joy of implementing a moving target "draft" RFC :-)