Re: [httpapi] RateLimit Header client implementations

[Alex Martinez <[e-mail]>]

Hi Darrel,

On Sun, Jan 10, 2021 at 4:27 PM Darrel Miller <[e-mail]>
wrote:

> Alex,
>
> Thanks for the additional context.
>
> You are right, the immediate effect is the same. That said, you would be
> lacking some extra information about the nominal quota units and duration
> of the current window and the windows applying after this one is elapsed
> (ie. after recovery you'd have information about the expected rates, and
> those could also signal some sort of punitive policy), though that
> information might be next to useless in the current window since the
> intended effect is to stop traffic altogether for a while. Yet it would not
> work in a closely related scenario in which you would have some partial
> maintenance work but keeping the ability to serve clients in a degraded
> service manner -- that is, unless you kept giving clients shorter
> no-service windows interleaved with service responses as usual, hence
> generating a lot more wasteful traffic.
>
> Would be useful to clarify that these additional headers are intended to
> support scenarios where rate limiting constraints applied by a service are
> dynamic over time?
>

Sure, we can look into clarifying this - perhaps my own reading of the
document makes this obvious to me having worked on rate limiting stuff for
some time.

>  Yes, I believe that because there is no standardization there's been
> little to no effort in writing such adaptive code in generic HTTP clients,
> but this is pure speculation. I think it is very likely that most people
> doing so are the ones writing service specific clients, and in many cases
> they could be the same people that wrote the service in the first place,
> unless the service happens to see lots of usage across the board with many
> independent clients.
>
> I look forward to seeing some feedback from implementers on the value
> derived from generic client code that handles these headers.
>

Understandably these don't exist yet - the easy thing to do is implementing
support for these in servers that do some sort of rate limiting or
integrate with a component that does, and that's why most (all?) of the
implementations we know of are server code. I also look forward to the
possibilities in clients, and it would be great to have basic support in
the most commonly used HTTP client libraries, but admittedly the
implementation work is not trivial. I don't really know whether such
projects would go for an I-D even if it's already on the standards track,
but we can certainly ask!

Cheers,
  Alex

>