Sujet : http
-
Bien utiliser les codes de statut HTTP : le premier aiguillage du client
Les clients, caches et agents décident uniquement à partir du code de statut s'il faut réessayer, recharger ou abandonner : 201/204 pour un succès avec ou sans corps, 401 contre 403 pour une authentification manquante contre une autorisation manquante, 409/412/428 pour les conflits et les conditions préalables, 429 et 503 avec Retry-After pour signaler « plus tard ». Un 200 accompagné d'un objet d'erreur trompe tout le monde.
-
Respecter Retry-After comme borne inférieure
Planifier les nouvelles tentatives à partir de l'une ou l'autre forme de Retry-After, tout en respectant l'échéance de la tâche et en évitant les requêtes répétées prématurées.
-
Ralentir côté client : Retry-After, en-têtes RateLimit et budgets par hôte
Face aux réponses 429 et 503 et aux en-têtes indicatifs de limitation de débit, un agent doit respecter exactement Retry-After ou, à défaut, appliquer un backoff exponentiel avec aléa, lire les champs RateLimit et RateLimit-Policy fournis par le serveur pour ralentir avant la limite, maintenir un budget par hôte et par clé et ne jamais retenter une écriture non idempotente sans clé d’idempotence.
-
Compression des réponses : où la faire et quoi en exclure
Compresser les réponses textuelles (HTML, JSON, Markdown) au niveau du proxy ou de l'application, ignorer le contenu déjà compressé et le contenu en streaming, garder des ETags honnêtes à travers les encodages, et définir Vary: Accept-Encoding.
-
Le traçage distribué en bref : spans, identifiants parents et W3C Trace Context
Une trace est un arbre de spans, chacun avec un identifiant de trace, son propre identifiant de span, un identifiant de span parent, des horodatages, des attributs et un statut ; l'en-tête W3C traceparent transporte l'identifiant de trace, l'identifiant parent et un indicateur sampled au-delà des frontières de processus, et un service qui se contente de retransmettre les deux en-têtes garde malgré tout les traces cohérentes.
-
Pages 404 personnalisées et soft 404 : servir la page d'erreur avec le statut d'erreur
Une page 404 personnalisée n'aide les utilisateurs que si elle est servie avec le statut 404 ; une page « introuvable » servie avec un 200 est un soft 404 que les robots d'indexation continuent d'explorer et que les moteurs de recherche excluent. La directive error_page de nginx peut réécrire le statut (error_page 404 =200 ...), ce qui est exactement la manière dont les soft 404 sont créés par accident ; conserver le statut, rendre la page utile, et vérifier avec curl -I.
-
La politique de même origine (Same-Origin Policy) : ce qu'est une origine et ce qu'elle isole
Une origine est le triplet schéma, hôte et port d'une URL. Un script peut lire et modifier des documents, du stockage et des réponses de même origine ; les lectures cross-origin sont bloquées par défaut, tandis que les écritures cross-origin telles que les soumissions de formulaire et l'intégration telle que les images et les scripts sont généralement autorisées. CORS assouplit les lectures ; des défenses contre le CSRF restent nécessaires.
-
Utiliser fetch avec des délais d'expiration et AbortController
Une promesse fetch n'est rejetée qu'en cas d'échec réseau, pas en cas de statut d'erreur HTTP, et elle n'a par elle-même aucun délai d'expiration. Passer un AbortSignal combinant AbortSignal.timeout et un contrôleur de l'appelant, vérifier response.ok, et distinguer dans le catch TimeoutError, AbortError, les erreurs réseau et les erreurs HTTP.
-
Concevoir des opérations idempotentes et des nouvelles tentatives sûres
Une opération est idempotente lorsque son exécution répétée produit le même effet qu'une exécution unique ; la RFC 9110 fixe cela pour les méthodes HTTP, et un en-tête de clé d'idempotence transpose cette propriété à POST. Stocker la clé avec une empreinte et le résultat, signaler les conflits par 409 et 422, supprimer les clés après un délai documenté.
-
Server-sent events contre WebSockets
Les server-sent events diffusent des événements textuels du serveur vers le client sur du HTTP simple, avec reconnexion automatique et identifiants de dernier événement ; les WebSockets offrent un canal bidirectionnel capable de transporter du binaire avec son propre protocole. Choisir SSE pour des mises à jour à sens unique et les WebSockets quand le client doit envoyer fréquemment.
-
Appeler l'API TypeSafe depuis un agent : forme de la requête, erreurs, tentatives et épinglage de version
Le contrat documenté dont un agent a besoin pour appeler Jev sans couche de discussion (chat) : POST /v1/systemone avec une clé Bearer, un état (state), un nom de modèle et une carte de questions typées ; des réponses indexées comme les questions, plus un bloc d'usage ; les codes 401, 422, 429 et 529 avec un backoff exponentiel ; des alias qui évoluent et des identifiants versionnés qui restent fixes ; les valeurs par défaut du SDK pour les tentatives, et la compétence (skill) dédiée aux agents de codage.
-
L'en-tête Link et les types de relation de lien
La RFC 8288 permet à toute réponse HTTP de porter des liens typés dans un en-tête Link : <cible>; rel="relation" plus des paramètres facultatifs anchor, hreflang, type, title et media. Les noms de relation proviennent du registre IANA (next, prev, canonical, alternate, describedby, preload) ou sont des URI absolues pour des extensions privées. C'est ainsi que les réponses non HTML pointent vers leurs voisines, et comment le code 103 Early Hints indique à un navigateur quoi récupérer en avance.
-
Les bases de Web Push : abonnements, clés VAPID et le service de push
Un navigateur s'abonne auprès du service de push de son éditeur et remet à la page un point de terminaison (endpoint) plus des clés ; le serveur applicatif envoie par POST des messages chiffrés à ce point de terminaison avec un en-tête TTL et un JWT VAPID (ES256, aud = origine du service de push, exp d'au plus 24 heures) dont la clé publique a été transmise à PushManager.subscribe comme applicationServerKey. Un 201 signifie accepté, pas délivré.
-
Plans de site et adresses canoniques : un contenu, une adresse
Chaque contenu devrait avoir exactement une adresse HTTPS canonique, déclarée sur la page elle-même ; les jumeaux comme les versions Markdown ou JSON y renvoient par un en-tête Link, les paramètres sans effet sur le contenu ne créent pas de nouvelles adresses, et le plan de site ne liste que des adresses canoniques avec des dates de modification véridiques.
-
HEAD et OPTIONS : à quoi ils répondent et à quoi les clients les utilisent
HEAD est un GET sans corps : même statut et mêmes en-têtes (Content-Length et Vary peuvent être omis), mise en cache possible, utilisé pour la vérification de liens, les sondes de taille et les contrôles de fraîcheur. OPTIONS demande quelles options de communication une ressource ou le serveur entier (OPTIONS *) prend en charge, reçoit typiquement une réponse avec Allow, n'est pas mis en cache, et porte les préflights CORS avec Access-Control-Request-Method.
-
Parcours de conception d'un raccourcisseur d'URL : génération de clés, statut de redirection et contrôles d'abus
Un parcours de conception pour un raccourcisseur d'URL : des clés base62 aléatoires avec nouvelle tentative en cas de collision, un chemin de redirection touchant un seul cache et un seul stockage, 302 plutôt que 301 lorsque les cibles doivent rester révocables et comptables, des contrôles d'abus côté création, et une liste de ce qu'il ne faut pas construire en premier.
-
Réduire les chaînes de redirection à un seul saut augmente la part des requêtes de robots d'indexation qui se terminent par un 200 sur un grand site
Hypothèse : sur un site comptant des dizaines de milliers d'URL et des redirections accumulées, réécrire chaque chaîne pour que chaque ancienne URL réponde par une seule redirection vers sa cible finale augmente mesurablement la part des requêtes des robots d'indexation qui atteignent une page en 200 dans un volume de requêtes quotidien fixe, parce que les robots dépensent des requêtes à chaque saut ; un test avant-après proposé sur les journaux serveur.
-
Les JSON Web Tokens : ce qui peut mal tourner et les réponses de la RFC 8725
Les JWT sont des revendications signées, pas des secrets chiffrés ; valider l'algorithme contre une liste blanche, vérifier l'émetteur, l'audience et l'expiration, garder des durées de vie courtes, ne jamais accepter « none », et se rappeler qu'un jeton sans état ne peut pas être révoqué sans une liste côté serveur.
-
Points d'accès en masse et signalement des échecs partiels
Un point d'accès en masse réussit ou échoue en bloc, ou bien signale le résultat de chaque élément ; un simple 200 ne peut pas exprimer un succès partiel, d'où la nécessité de choisir un comportement par point d'accès, d'indexer les échecs par position, de plafonner la taille du lot et d'appliquer l'autorisation et la limitation de débit à chaque élément.
-
Choisir délibérément les codes de statut HTTP
Le code de statut est le premier élément sur lequel un client fonde sa décision : 200/201/204 pour le succès, 304 pour l'absence de changement, 400/422 pour une entrée invalide, 401/403 pour distinguer les identifiants de l'autorisation, 404 pour une ressource absente, 409/412/428 pour les conflits et les préconditions, 429/503 pour réessayer plus tard.
Lisible par machine : JSON