Mitigating DoS

[mnot]

Clients MUST validate the received values to mitigate those risks.

This doesn't seem practical; how would validation help? What are they looking for?

[ioggstream]

For example, implementations are expected to validate received values like

RateLimit-Remaining: 1_000_000
RateLimit-Reset: 1

Or

RateLimit-Reset: 1_000_000

The same goes for other fields, e.g.

Retry-After: 1_000_000

A similar practice, in a different context though, is mentioned in https://martinthomson.github.io/http-request-date/draft-thomson-httpapi-date-requests.html#name-date-not-acceptable-problem

Hints are welcome!

[darrelmiller]

Considering the objective of the RateLimit headers is to allow a client to avoid being throttled, the consequence of a client ignoring the RateLimit-* headers is just a client getting throttled. If we believe that a client may need to protect itself against malicious values injected into these headers, then I it should be sufficient to give clients the permission to ignore the headers if they believe the values are not reasonable.

Suggest wording like:

Clients MAY choose to ignore the received values if they have reason to believe that the values are not valid.

However, considering that processing these headers is optional for a client anyway, I'm not sure this comment is absolutely necessary.

[mnot]

Part of the problem here is that "valid" is being used in different senses:

• to indicate that it's a valid Structured Field
• to indicate that it's semantically valid (e.g., "too big")

For the latter, since it's so fuzzy (at least to date), I'd suggest using something like "reasonable" instead.