Re: A new HTTP response code for "OK but busy"

APIs will continue to handle whatever throttling they have, and the 
newer versions will adapt to changes to HTTP, just as they always have.

But this isn't intended just for APIs. It's intended for everything, 
including web sites serving HTML.

the server could send the content normally but set the status code to 
229 if generating the response uses resources (CPU, time, memory) over 
certain thresholds. Normal web browsers could use it, but possibly adapt 
how they request other assets (e.g. lazy loading instead of prefetching 
additional content from the website).

Ideally search engine crawlers could use it, although the major ones 
generally ignore HTTP 429, but treat the response as an error. (I know 
this from experience.)
Search engines crawlers will still be able to index the content. The 
polite ones will back off, the impolite ones will continue being 
impolite but at least they had fewer error pages.


On 28/11/2024 18:05, Tim Bray wrote:
> I would just note that there is a huge amount of of 
> throttling/fallback/retry code already deployed around more or less 
> every popular API, both server and client side, which relies on 429, 
> and it seems to work acceptably well.  You’d need to demonstrate a 
> real benefit-at-scale to make people even consider rebuilding this 
> around a new HTTP status. -T
>
> On Nov 28, 2024 at 3:17:58 AM, Robert Rothenberg <robrwo@gmail.com> wrote:
>> It would be nice to detect when the server is unusually busy and
>> indicate in the response that the client should retry later, but in a
>> way that indicates the response content is not an error.
>>
>> HTTP 429 (too many requests) and HTTP 503 (server unavailable) are not
>> really relevant as they suggest there is an error.
>>
>> It would be useful to have something like HTTP 229 that means "Ok, but
>> busy". The response would include a Retry-After header, and the body
>> would be a normal response body as if an HTTP 200 was received.
>>
>> The meaning of this response is that the content fulfils the request,
>> but the server is "busy", and that future requests before the
>> Retry-After header might be rejected.
>>
>> The server is not required to (and should not) explain why it is busy.
>> It may be due to high CPU load, high memory usage, or too many requests,
>> or too many requests from a specific agent or network.
>>
>> The client should not infer anything other than the response body is
>> useful but to discontinue making additional requests until after the
>> recommended time.
>>
>>
>>
>>