esi-issues
esi-issues copied to clipboard
Expose 'Date' header to assist with error rate limits
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:
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:
- [x] Feature request description is provided
- [x] 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
- [x] Meta feature, applies to all routes