Open twifkak opened 2 years ago
OK, Vercel doesn't support custom cache keys, which we need to separate SXG responses (for SXG crawlers) from non-SXG (for browsers and non-SXG crawlers). Judging by this flow diagram we should target Edge Middleware which isn't cached, so that users can still enable caching behind it.
Perhaps the simplest option is to support some external DB with a free tier.
To clarify the "use edge caching and set up internal HTTP APIs" idea: Request the outcome of the last step. The handler for each step recursively fetches the previous step, and sets long cache headers for successful outcomes.
serve_preset_content
would be handled by Vercel Functions, not Middleware, so it could be cached. When handling requests for the following URLs:
cert_url_dirname
prefix: fetch /.well-known/sxg-internal/acme/download_certificate
and /.well-known/sxg-internal/ocsp/response
. If successful, generate a cert-chain+cbor
and serve with a 3.5 day cache lifetime. Else, serve an error response with a short lifetime (1 minute?).acme/download_certificate
: fetch finalize_signing_request
. If successful, perform the next step of ACME and serve the final state with a 45-day cache lifetime. Else, error response with a short lifetime.acme/finalize_signing_request
: fetch check_challenge_finished
. Ditto if successful/error.acme/check_challenge_finished
: fetch request_challenge_validation
. Ditto if successful/error.acme/request_challenge_validation
: Perform initial step. Ditto if successful/error.ocsp/response
: Fetch from OCSP responder. If successful, set a 3.5 day cache lifetime. Else, set a short lifetime (10 minutes?).(We may also want to sign these URLs so external requestors can't forge them.)
There are
twothree types of Vercel Functions and I'm not sure of the compare/contrast. One comparison here. There is a community Rust binding (API).For storage, one can connect to an external DB but perhaps a more config-free approach would be to use edge caching and set up internal HTTP APIs for certs/OCSP.