1
votes

Pourquoi la "dernière modification" est-elle incorrecte sur Google Cloud Platform App Engine?

J'ai déployé mon site Web sur Google Cloud Platform App Engine à plusieurs reprises. En utilisant le réglage comme suit:

app.yaml

runtime: nodejs10

Tout a bien fonctionné lorsque je l'ai testé sur l'hôte local. Mais quand je l'ai déployé sur Google Cloud Platform. L'en-tête de réponse affiche toujours la last-modified: Tue, 01 Jan 1980 00:00:01 GMT . J'ai vérifié sur [my-web].df.r.appspot.com pour m'assurer que le problème provient de Google Cloud Platform.

est-ce que quelqu'un a une idée?

Mis à jour 2020-10-07
Pour toute personne confrontée au même problème, n'hésitez pas à participer à la discussion ici .


0 commentaires

4 Réponses :


0
votes

Cela semble être un problème causé par le cache. Pour vous assurer que le nouvel index.html est déployé, vous devez exécuter «gcloud beta app deploy --no-cache», des champs supplémentaires peuvent devoir être ajoutés tels que app.yaml comme mentionné ici . Cela garantirait que le nouveau index.html associé à votre version est poussé dans le conteneur.


2 commentaires

Merci d'avoir répondu! J'ai essayé votre suggestion, mais cela n'a pas fonctionné. :(


Salut Benjamin, il semble que ce problème affecte plus de personnes, mais lorsque vous recherchez un outil de suivi des problèmes GCP, personne ne l'a encore signalé. Je vous recommande d'ouvrir un outil de suivi des problèmes ici issuetracker.google.com/issues/… pour le signaler directement à l'équipe GCP.



0
votes

Nous rencontrons le même problème que la version précédente d'index.html récupérée par les clients après le redéploiement d'une application standard appengine. Ce problème semblait commencer à la mi-août. Nous avons d'abord constaté que l'ajout d'une ligne au fichier HTML du client comme: semblait résoudre le problème. Mais cela ne fonctionne plus.


0 commentaires

0
votes

J'ai eu le même problème avec l'ancien index.html servi. Le problème était avec le etag généré. Même si les fichiers ont changé, l' etag est resté le même.

Cela a provoqué la app.yaml du fichier à partir du cache du navigateur avec le code d'état 304. Le coupable était mon fichier app.yaml , qui était

runtime: nodejs10

Le changer en dessous a résolu le problème.

env: standard
runtime: nodejs10
default_expiration: '14d'

handlers:
  - url: /static
    static_dir: build/static
    secure: always

  - url: /(.*\.(json|ico))$
    static_files: build/\1
    upload: build/.*\.(json|ico)$
    secure: always

  - url: .*
    static_files: build/index.html
    upload: build/index.html
    expiration: '5s'
    secure: always


0 commentaires

0
votes

Apparemment, il s'agit d'un comportement par conception car tous les horodatages sont rendus nuls lors du déploiement par le moteur d'application. voir: https://issuetracker.google.com/issues/168399701

J'envoyais moi-même les fichiers statiques en utilisant express. Je l'ai donc résolu en ne définissant pas les en-têtes etag et last-modified. Par exemple:

app.get("/*", async (req, res) => {
  return res.sendFile("index.html", { root, lastModified: false, etag: false });
});

Ou pour les fichiers individuels:

app.use("/", express.static(root, { etag: false, lastModified: false }));


0 commentaires