You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
Feature Request
Expose
Date
header in responses by adding it toAccess-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
andX-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
includesDate
Checklist
Check all boxes that apply to this issue:
The text was updated successfully, but these errors were encountered: