Looking at Generic Request, I see we don't have any throttling logic. I know this can cause failures for scripts that are checking versions via GitHub APIs (such as garbo).
The straightforward fix for them is to just fail if they get rate limited, but I wonder if there are more robust options we could build out, and if so what they should do.
This is a discussion and not a feature I'm going to put together yet; I'm not even sure what the "right" behavior is.
GitHub (and AWS and other services implementing rate limits) implement the RFC-6585
We could honor that, but what should we do if a request is rate limited?
My simplest thought is that if response header Retry-After is present and not null, then add "\nRate Limited Request: Retry-After: <value>" to the Response Text, so that the client can parse and deal with it (is it 5 seconds? 50? 3600?).
Can anyone think of ways this might break things? I want to do the least possible change and still be useful.
I also don't know if KoL supplies 503/429 messages, since that mechanism is designed to cover cases of scheduled maintenance with a known end-period. Which sounds like nightly maintenance, but I'd have to see the headers of maint.php to see if they're sending that header or what the values might be.
The straightforward fix for them is to just fail if they get rate limited, but I wonder if there are more robust options we could build out, and if so what they should do.
This is a discussion and not a feature I'm going to put together yet; I'm not even sure what the "right" behavior is.
GitHub (and AWS and other services implementing rate limits) implement the RFC-6585
Retry-After
header. We could honor that, but what should we do if a request is rate limited?
My simplest thought is that if response header Retry-After is present and not null, then add "\nRate Limited Request: Retry-After: <value>" to the Response Text, so that the client can parse and deal with it (is it 5 seconds? 50? 3600?).
Can anyone think of ways this might break things? I want to do the least possible change and still be useful.
I also don't know if KoL supplies 503/429 messages, since that mechanism is designed to cover cases of scheduled maintenance with a known end-period. Which sounds like nightly maintenance, but I'd have to see the headers of maint.php to see if they're sending that header or what the values might be.