Dans la barre d'adresse :
https://login.mail.com/login#.[...*]-header-login1-1
Dans l'écran en dessous :
{"error":{"status-code":"429","message":"Too Many Requests","request-id":"2e4b49b6b2747a23b734372789aa8553"}}
Ceci ou encore erreu 500 (?) depuis** cette nuit./HGL
* J'omets les chiffres, ne sachant pas s'ils pourraient révéler mon compte.
** À l'heure, c'est 16:16, Paris.
Je viens de vérifier le code erreur.
ReplyDeleteDEFINITION:
What is HTTP 429 Too Many Requests?
HTTP 429 Too Many Requests is a client error status code indicating you’ve exceeded the allowed request rate. It’s part of the 4xx family of status codes that signal client-side problems rather than server errors.
Rate limiting acts as traffic control. Just as highways have speed limits, APIs enforce request limits to maintain stability for all users. When you exceed these limits, the server responds with 429 instead of processing your request.
Rate limiting helps protect backend CPU and network capacity from DDoS attacks and excessive HTML scraping, while also defending against bots, brute-force attacks, and repeated login attempts that can overload servers or degrade response times.
BON FORMAT:
ReplyDeleteAnatomy of a 429 response
A properly formatted 429 response includes headers that tell you how to handle the situation:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1699564800
Content-Type: application/json
{
"error": "rate_limit_exceeded",
"message": "You have exceeded the rate limit of 100 requests per minute",
"retry_after": 60
}
Key response headers include:
Retry-After → seconds to wait before retrying
X-RateLimit-Limit → maximum requests allowed
X-RateLimit-Remaining → requests left in current window
X-RateLimit-Reset → Unix timestamp when quota refreshes
Header names vary by API. Some use RateLimit-* without the X- prefix, while others use custom conventions. Always check the API documentation.
NOTE:
Il n'y avait pas de "retry after"
LES CAUSES:
ReplyDeleteCommon causes of 429 errors
Exceeding request rate limits
Sending too many requests in a short period is the most common cause. This happens with loops that fetch data for multiple resources without pacing. For example, retrieving user data for 1,000 users in a tight loop quickly triggers rate limits.
Burst traffic patterns also cause problems. Even if your average request rate stays within limits, sudden spikes can exceed per-second thresholds.
Concurrent request limits
Some APIs limit the number of simultaneous connections, not just the frequency of requests. Making 50 parallel requests might violate concurrent limits even if your per-minute rate is acceptable.
This becomes problematic in distributed systems where multiple servers share API credentials. Each component individually stays reasonable, but collectively they overwhelm the concurrent request threshold.
Endpoint-specific limits
Write operations, such as POST, PUT, and DELETE, often have stricter limits than read operations. Search and query endpoints tend to impose lower limits because they’re resource-intensive. An API might allow 1,000 GET requests per hour but only 100 POST requests.
Aggressive retry logic
Poorly implemented retry logic often makes rate limiting worse. Applications that immediately retry failed requests create retry storms that amplify the problem. Each retry consumes another request from your quota.
How rate limiting works
APIs use different rate-limiting algorithms:
Fixed window limits reset at specific intervals. For example, 100 requests per minute resets at the top of each minute. This can cause traffic spikes at reset boundaries.
Sliding window limits track requests over rolling time periods, calculating your rate at any moment based on the past 60 seconds. This provides smoother traffic distribution but requires more complex calculations.
Token bucket algorithms offer the most flexibility. Tokens are added at a constant rate, and each request consumes one token. The bucket has a maximum capacity, allowing brief bursts when tokens have accumulated. AWS API Gateway, Stripe, and many modern APIs use token bucket algorithms.
APIs apply rate limits at different scopes: per API key, per user account, per IP address, per endpoint, or globally across all users. Many APIs track limits per user or IP address, measuring the number of requests within a time window.
NOTE:
Les plus communs limites sont per utilisateur individuel ou par ordinateur (IPA-adress).
Je venais à d'ordinateurs frais et je me connecte au courriel, certes plus souvent qu'une fois par jour, mais pas plus souvent que, genre 5 fois par une heure.
Plutôt que d'avoir le compte du courriel ouvert une session entière, quand je vais sur des autres comptes, je me déconnecte et ensuite, quand j'aurais besoin, reconnecte.
CONCLUSION:
ReplyDeleteLes plus probables raisons de ceci est si, a) quelqu'un avec privilège administrateur sur l'ordinateur spam le courriel de l'adresse IPA, b) quelqu'un ayant accès à mon mot de passe (voir a tracage des boutons poussés, ou hypnose) abuse pour se connecter, déconnecter, reconnecter etc tous les minutes, par bot. Ou encore c) quelqu'un a mis une limite inférieur du standard pour mon compte.
Dans les deux cas a et b, c'est un procédé criminel, dans le cas c, ça pourrait être tyrannie par quelqu'un ayant le statut (abusivement acquis) de mon psychiatre et qui applique un protocol contre la diagnose (venue de la Chine communiste en 2004) de "dépendance d'internet".
Dans les trois cas, c'est immoral.
Moins probable, mais possible, les gens qui me suivent (dont certains de manière inimicale) se mettent en ligues de 1000 utilisateurs le plus proches de moi, pour déborder le serveur du courriel le plus proche de moi.
ReplyDelete