esi/esi-issues

Expose 'Date' header to assist with error rate limits

Opened this issue · 0 comments

Feature Request

Expose Date header in responses by adding it to Access-Control-Expose-Headers.

Use case

To guarantee we obey the ESI error rate limits, two headers are returned with every response: X-Esi-Error-Limit-Remain and X-Esi-Error-Limit-Reset.
The former represents how many errors a client still has available before being throttled/blocked, while the latter represents the number of seconds until the limit is reset.

To determine the most recent response we need to rely on the timestamp of each response, but these are not available due to CORS.

Applications running in a browser will see cached responses where the values of these headers should be ignored. Unfortunately, there is no reliable mechanism to distinguish responses are cached from those that aren't, thus making it hard to guarantee rate limits are obeyed:

Screenshot_2023-06-21_at_12 15 44

Exposing the Date response header allows to establish a total-order on the responses, which allows to infer the state of the error limit mechanism on the server, overcoming the challenges of dealing with caching, concurrent requests and multi-tenancy (multiple distinct applications behind the same IP).

Example return

Header Access-Control-Expose-Headers includes Date

Checklist

Check all boxes that apply to this issue:

  • Feature request description is provided
  • Use case exists
  • Feature requires a new route
  • Feature adds data to existing route
  • Feature requires new auth scope
  • Feature can reuse existing scope
  • Feature does not require auth
  • Meta feature, applies to all routes