Could Limit be an item instead of a list?

[ucarion]

This is still a suggestion I haven't had enough time to really think through, but I thought it might be worth discussing.

The document currently says that for Limit, the server can give back a list of all of the quota policies currently "in force". But for Remaining and Reset, the server can only give back (without resorting to nonstandard extensions) those values for the policies with the least remaining quota. It seems like it would be more "consistent" to instead have:

1. Remaining and Reset both have a similar syntax to Limit, where you can give a list with w= parameters. (This is what I'm getting at in #19.) Or,

2. Limit works like Remaining and Reset, where you only talk about the policy with the least remaining quota. We could still keep the w= parameter, just no list. This is what I'm proposing here.

From talking offline, it seems the intention is that only the first value of Limit is actionable; the rest is just informative. I question whether we want to put information that isn't machine-actionable in an HTTP header/trailer. So what if we took RateLimit-Limit and made it be a single SFV item, instead of a list of items?

In the simplest case, this changes nothing. RateLimit-Limit: 100 is equivalent either way. So the document would still be backwards compatible with most of what's out there, modulo the header name.

RateLimit-Limit: 100, 100;w=10 would become just RateLimit-Limit: 100;w=10.

Obviously, the case that needs refactoring is something like:

RateLimit-Limit: 5000, 1000;w=3600, 5000;w=86400

Servers could either only mention the lowest window, or they could declare their other windows with a parameter? If we want to keep the informative notion of multiple windows standardized, we can even standardize the name and format of this parameter. Here's one possible idea:

RateLimit-Limit: 5000;w=86400;windows="1000,3600;5000,86400"

[ioggstream]

We thought about it, but we decided to retain the current format to always have the three integers as mandatory actionable content. This avoids unnecessary complications for the average users while allowing advanced users to process fields with SFV using the first value as the key for the quota policy. The point is that

• we do not forbid to process the quota-policy,
• but we want that clients are not forced to do so.

Does it make sense to you? Is there an use case not covered by the current setup?

[ucarion]

Are you saying that you want the spec to be usable even if someone doesn't want to implement SFV? If so, how would you have people do that? By saying that clients can only parse RateLimit-Limit up to the first , character, if they don't want to validate SFV data?

If so, I think this language may be a problem:

https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#text-parse

If parsing fails -- including when calling another algorithm -- the entire field value MUST be ignored (i.e., treated as if the field were not present in the section). This is intentionally strict, to improve interoperability and safety, and specifications referencing this document are not allowed to loosen this requirement.

By saying that RateLimit-Limit is a list, but that implementations can ignore things past the first ,, I think the document would basically be saying that parse errors after , can be silently dropped, and the data before the , can be understood anyway. I'm pretty sure the SFV folks would object to that.

From reading and implementing SFV, I get the strong sentiment that it is an all-or-nothing sort of spec. You need to buy into the fact that it dictates how parsing happens (and that implementations need to use an SFV library), or you need to give up using it entirely.

[ioggstream]

In https://ietf-wg-httpapi.github.io/ratelimit-headers/draft-ietf-httpapi-ratelimit-headers.html#section-4-8

The quota-policy values and comments provided in RateLimit-Limit are informative and MAY be ignored.

we state that they may be ignored wrt the client behavior, without mentioning the parsing.

About being able to treat a field as a non-structured field, this can be useful to the discussion https://github.com/httpwg/http-extensions/pull/1666

Sending implementations MUST generate valid Structured Fields. Receiving implementations SHOULD use a Structured Fields parser, but MAY reuse an existing parser [...] In doing so, they SHOULD implement the following constraints, to aid in a smooth transition to a full Structured Field parser and prevent interoperability issues: [...]

[ioggstream]

According to this Mark's comment https://github.com/ietf-wg-httpapi/ratelimit-headers/pull/75#pullrequestreview-821018455 it's better to stick to SF, so the original point of @ucarion stays.

sf-integer [, 1#sf-item]

when parsing quota-policies To ease the transition from old implementations, I would just suggest then that ratelimit providers SHOULD support a flag to enable/disable the providing of service-quota information.