FAQ et dépannage

Cette page fournit des réponses aux questions fréquentes sur App Hosting.

App Hosting : questions fréquentes

Limites générales et dépannage de App Hosting

  • En raison d'un problème dans l'infrastructure Cloud Run, la création ou la mise à jour de ressources peut être plus lente que prévu dans certaines régions, comme us-central1. Si la latence de déploiement pose problème dans une région donnée, Google recommande de déployer dans une autre région.

  • Le CDN pour App Hosting ne peut inclure qu'un ensemble spécifique d'en-têtes de requête dans ses clés de cache. Il s'agit des produits suivants :

    • En-têtes Next.js : RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch et Next-Url.

    • En-têtes standards Cloud CDN : Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources et X-Origin.

    Notez que si une réponse contient un en-tête Vary avec une valeur non listée ici, le CDN ne la mettra pas en cache.

  • Les fichiers statiques non mis en cache sont diffusés à partir de Cloud Run. Dans une version ultérieure, ils seront stockés et diffusés à partir de l'origine App Hosting pour de meilleures performances.

  • La console Firebase peut afficher par intermittence une erreur "La compilation est introuvable et n'est pas valide" lors de la création du backend.

  • Tous les backends d'un même projet partagent une organisation/un compte GitHub. Ils peuvent être connectés à différents dépôts de cette organisation ou de ce compte. Pour créer des backends connectés à différents comptes GitHub, placez-les dans des projets distincts.

Limites et dépannage des applications Angular

Bien que la compatibilité de App Hosting avec Angular soit en cours de développement et d'expansion, elle présente les limites suivantes :

  • I18n : bien que la fonctionnalité I18n de base fonctionne, la navigation directe vers les pages SSR peut entraîner des erreurs.
  • Localisation : la création de versions pour différents paramètres régionaux n'est pas possible.
  • Builders : seul le compilateur d'applications est actuellement compatible.
  • Environnements et outils Monorepo : les projets Angular qui ont plus d'une cible d'application échoueront. Pour une compatibilité plus complète avec les monorepos, utilisez Nx.

Erreurs HTTP 400 et confiance dans le proxy dans Angular SSR

Si votre application Angular déployée sur Firebase App Hosting rencontre des erreurs HTTP 400 (requête incorrecte), des blocages de validation de l'hôte ou des échecs de confiance du proxy, suivez la solution recommandée pour votre version d'Angular :

  • Angular v19, v20 et v21 : vous pouvez résoudre ces erreurs HTTP 400 de deux manières :
    • Mettre à niveau les dépendances : exécutez npm update @angular/core @angular/ssr pour installer la dernière version du correctif pour votre version actuelle d'Angular.
    • Configuration manuelle : appliquez une configuration de remplacement au niveau du code en définissant trustProxyHeaders: true dans la configuration de votre serveur (consultez Configurer les en-têtes de proxy de confiance dans la documentation Angular).
  • Angular v22 : la première compilation sur un nouveau backend peut renvoyer des erreurs 400. Pour résoudre le problème, générez un deuxième build. Toutes les compilations suivantes devraient fonctionner comme prévu.

Limites et dépannage de Next.js