RateLimit-Reset is set to delay-seconds in IETF draft, not UTC time

[estensen]

From the docs:

The middleware automatically set the following headers, conforming to the latest RFCs: ... X-RateLimit-Reset - UTC time when the limit resets.

In what I think is the latest IETF draft on RateLimit Header Fields for HTTP the header RateLimit-Reset is set to delay-seconds because it doesn't rely on clock synchronization and mitigates thundering heard if too many clients are given the same timestamp.

Will you consider changing and use delay-seconds?

Or is this what is also mentioned in the docs what enables a resolution higher than one second and focus more on rate limiting other services than HTTP?

[sethvargo]

Hey @estensen

I think those are still draft. For example, GitHub's X-RateLimit-Reset value is "The time at which the current rate limit window resets in UTC epoch seconds."

There's a difference between X-RateLimit-Reset and RateLimit-Reset though, since X- headers are defined by the application. If IETF accepts the proposal, we can add RateLimit-Reset as defined by the spec while keeping X-RateLimit-Reset be the UTC time.

However, since these things tend to change over time, I'm hesitant to add RateLimit-Reset now, since that proposal is still a draft.

[estensen]

Thanks for responding!

Was not aware of the X- headers being different. Feel free to close this if you don't want it as a reminder to look at it later.