reframe: HTTP Caching support

[lidel]

Reframe spec was added in #272, and it includes HTTP as an interoperable way of sending request-response dag-json messages.

Problem

Reframe messages used in contexts like indexers are queries, being able to cache popular responses could significantly reduce the cost and improve performance when running an indexer or a similar service.

Initial spec in #272 requested all requests to be over HTTP POST method.

Caching in POST-only API will be... really tricky:

• POST is not idempotent and not "cacheable" by default, or at least not the way one would think.
• Specs are vague around this, but in practice clients and CDNs work more or less like this:
  • HTTP Caching model is around "resources", not "responses":
  • if you set Cache-Control or Expires headers AND set Content-Location on POST response, then response payload will be cached and returned for any future GET requests to the Content-Location – bit sketchy, and may not work this way everywhere
  • POST requests will not benefit from any preexisting cache, because they potentially mutate the resource, overriding anything that was cached.

Search for solution

Ideas welcome, feel free to comment below

[lidel]

Below are my initial ideas how we could get "reframe caching on HTTP":

• (A) Define custom caching based on the hash of the message in POST request (dag-json body)
  • pro
    • easy to implement (when compared to options (B) and (C))
  • con
    • will only work in places where we are able to adjust cache strategy on the server/CDN
• (B) There is IETF proposal to add QUERY HTTP method, which is idempotent: https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html
  • pro
    • JS running in browser can send arbitrary request method, so this should work fine (fetch("https://cid.contact/reframe", {method: 'QUERY'}))
    • easier to get CDNs to set up caching of QUERY than POST, the spec states that cache key "MUST incorporate the request content"
  • con
    • this is RFC draft
• (C) add support sending idempotent (or cacheable for some time) queries as a GET with reframe message in ?msg=<dag-cbor-in-multibase> query parameter OR /reframe/<dag-cbor-in-multibase> path arg. (path arg is prefered as some HTTP caches ignore query params and require additional setup)
  • pro:
    • standard HTTP caching works out of the box everywhere
  • cons:
    • there will be artificial message size limit depending on max URL length on specific runtime, so we still need to support POST

[BigLep]

Per 2022-06-07 conversation: for option C:

1. we believe path arg is better than query arg
2. it would be helpful to have a sense of how big findProvider is in practice to see how likely we are to hit the URL length limit.