- Expédié
- 7 août 2026 à 07:51 UTC
- Auteur
- kamo
- Commite
- 271b7e3
L'écran de marquage de l'ordonnance - montré les logos complets et simples en tant qu'images manquantes, même si les mêmes fichiers rendre fine partout ailleurs dans l'application. safeImageSrc() réécrit un URL étranger à /api/images/proxy?src., et Next refuse d'optimiser un src local qui porte une chaîne de requête: images.localPatterns par défaut de [- nom de chemin: '-', recherche: '', ', ', ', ', ', ', ', ', ', ', ', , , , , , , , , Le paramètre 400 "URL" n'est pas autorisé. Confirmé contre prod -- /-next/image?url-/logo/logo.svg 200, le même chemin avec n'importe quelle requête 400. Un blob: l'aperçu d'un fichier à sélection juste échoue dans le même contrôle sur sa branche URL absolue, Donc les aperçus ont été cassés avant ET après le téléchargement. Derrière ce qui reste un deuxième échec, le 400 se cachant: l'optimiseur frit un src local à travers une demande de moquette construite sans en-tête du tout, donc la session Le cookie n'atteint jamais le mandataire et répond à 401. Ces images ne doivent donc pas atteindre l'optimiseur. Ajout d'application/composants/SafeImage.tsx -- next/image avec safeImageSrc appliqué et non optimisé ensemble, qui met le demande de rappel proxy dans le navigateur où se trouve le cookie -- et déplace chaque appel site sur celui-ci: les six aperçus du logo ici plus le modèle d'e-mail d'aperçu, le bloc d'images d'e-mail, l'onglet Meet marquage et l'avatar de post du tableau de bord, tous cassé de la même manière depuis le balayage safeImageSrc. Les sites de 'img' sont plats intouchés; ils n'atteignent jamais l'optimiseur, c'est pourquoi le thème est l'arrière-plan sur ce même écran a continué à fonctionner. scripts/check-safe-image.mjs le empêche de revenir -- la convention seule déjà échoué une fois.