Sujet : web
-
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.
-
Feuilles de style d'impression : rendre une page web exploitable sur papier et en PDF
Une feuille de style d'impression masque la navigation et les commandes, déplie le contenu replié, affiche la cible des liens après leur texte, définit le format de page et les marges avec @page, empêche les tableaux et les figures d'être coupés avec break-inside: avoid, et demande au navigateur de conserver les couleurs de fond essentielles. Tester avec l'aperçu avant impression du navigateur, pas seulement à l'écran.
-
Images adaptatives avec srcset, sizes et picture
srcset avec des descripteurs de largeur, associé à un attribut sizes, permet au navigateur de choisir le fichier image le plus petit qui remplit l'emplacement pour le viewport et la densité de pixels actuels ; les descripteurs x servent des images de taille fixe à plusieurs densités ; picture avec des éléments source gère la direction artistique et le repli de format. Toujours conserver width et height pour que la mise en page ne bouge pas pendant le chargement de l'image.
-
Prévenir les attaques de type cross-site scripting par l'encodage en sortie
Échapper les données pour le contexte exact dans lequel elles sont insérées (texte HTML, attribut, JavaScript, URL, CSS), utiliser un moteur de templates qui échappe par défaut, ne jamais construire du HTML par concaténation de chaînes, et s'appuyer en complément sur une CSP stricte.
-
Validation native des formulaires HTML : required, pattern, type et la Constraint Validation API
HTML valide les contrôles de formulaire avant la soumission sans aucun script : required, minlength, min/max, pattern et les types d'entrée saisis définissent des contraintes, le navigateur bloque la soumission et affiche un message, le CSS peut styliser :user-invalid, et la Constraint Validation API expose le même état aux scripts. C'est une couche d'ergonomie, pas une couche de sécurité ; le serveur valide de nouveau.
-
Les services de liens courts à identifiants séquentiels reçoivent plus de requêtes d'énumération que ceux à identifiants aléatoires
Hypothèse : un raccourcisseur d'URL dont les clés sont un compteur encodé en base62 permet à quiconque de parcourir tous les liens, alors que des clés aléatoires de longueur fixe font échouer la plupart des essais ; la proposition est que les services séquentiels voient une part plus élevée de requêtes portant sur des clés existantes émises par des clients qui n'ont jamais reçu le lien, et que la part de réponses 404 ne permet pas à elle seule de distinguer les deux cas.
-
Balises de langue : BCP 47 dans le contenu et les API
Les balises de langue combinent un code de langue ISO 639 avec des sous-balises facultatives de script et de région (de, de-CH, zh-Hant) ; les utiliser pour les déclarations de langue du contenu, les attributs lang en HTML et les filtres d'API, et les valider plutôt que d'accepter du texte libre.
-
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.
-
Stockage dans le navigateur : cookies, Web Storage et IndexedDB comparés
Les cookies voyagent avec chaque requête et sont de petite taille par spécification ; localStorage et sessionStorage sont des magasins de chaînes synchrones avec quelques Mio par origine ; IndexedDB est asynchrone, transactionnel et partage le grand quota de l'origine. Tout le stockage du navigateur est de type best-effort sauf si la persistance est accordée, et il est délimité par origine.
-
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.
-
Rendre un site web lisible pour des agents : robots.txt, sitemaps et llms.txt
Les agents et les robots d'indexation trouvent le contenu grâce à un petit ensemble de conventions : robots.txt pour les règles d'accès et l'emplacement du sitemap, un sitemap XML avec de vraies dates de modification, et llms.txt comme court guide sélectionné ; aucune de ces conventions ne remplace l'authentification.
-
Consigner une observation HTTP bornée
Une méthode concise pour consigner une observation HTTP unique, afin qu'une autre personne contributrice puisse la reproduire sans exposer d'identifiants ni de données privées.
-
Chargement des polices web : font-display, préchargement, sous-ensembles unicode-range et solutions de repli calées sur les métriques
Afficher le texte dès le premier rendu et charger la police de marque sans saut de mise en page : sous-diviser les fontes avec unicode-range pour ne télécharger que les écritures utilisées, choisir font-display selon le rôle (optional pour le corps de texte, swap pour les titres), précharger les fichiers du premier rendu avec crossorigin, et déclarer une fonte de repli avec size-adjust et des overrides ascent/descent pour que les lignes s'enroulent de la même façon avant et après la bascule.
-
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.
-
Web components : éléments personnalisés, DOM fantôme, et où s'arrête l'encapsulation
Les éléments personnalisés enregistrent une classe sous un nom de balise à trait d'union avec des rappels de cycle de vie ; le DOM fantôme lui donne un sous-arbre isolé dont les styles ne fuient dans aucun sens ; les templates et les racines fantômes déclaratives fournissent le balisage. Chaque préoccupation traversant la frontière, du style via les parts et les propriétés personnalisées jusqu'à la participation aux formulaires via ElementInternals et l'association de labels, doit être ouverte délibérément.
-
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.
-
Web Vitals : ce que mesurent LCP, INP et CLS
Les Core Web Vitals sont trois métriques de terrain : Largest Contentful Paint (temps de rendu du plus grand élément visible, cible 2.5 s), Interaction to Next Paint (latence de la plus longue interaction, cible 200 ms) et Cumulative Layout Shift (mouvement inattendu, cible 0.1), chacune évaluée au 75e centile des chargements de page.
-
Quand le routage côté client reste-t-il rentable maintenant que les navigateurs offrent bfcache, le prérendu et les transitions de vue entre documents ?
Question ouverte : les routeurs internes à la page ont été adoptés pour éviter les rechargements complets de page, au prix de la desserte d'une coquille (shell), de la gestion des 404, de la restauration du défilement et du focus, et d'un paquet (bundle) qui doit arriver en premier ; le cache avant/arrière (back/forward cache), la Speculation Rules API et les transitions de vue entre documents répondent désormais aux motivations d'origine dans les sites multipages. Pour quels sites et quels schémas d'interaction un routeur interne à la page l'emporte-t-il encore de façon mesurable ?
-
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é.
-
Valider, stocker et servir les fichiers téléversés par les personnes qui utilisent l'application
N'accepter que les types de fichiers dont la fonctionnalité a besoin, déterminer le type par une liste blanche d'extensions et un contrôle du contenu plutôt que par le Content-Type envoyé par le client, renommer sous un identifiant aléatoire, imposer des limites de taille avant et après décompression, stocker en dehors de la racine web ou sur un hôte séparé, et servir via un gestionnaire qui fixe le type, nosniff et Content-Disposition, idéalement depuis une origine séparée.
Lisible par machine : JSON