Joie, c'est un avertissement (sisi, c'est marqué dedans).
Mieux, il est normal et souhaitable qu'on te le mette cet avertissement. Le problème serait plutôt que parfois on ne te le mette pas.
Alors voilà, quand tu fais un POST sur HTTP tu envoies des informations. Tu obtiens en retour un document qui résulte de cet envoi. Ca peut être par exemple un message de confirmation.
Que faire quand tu rafraichis la page ?
Il a plusieurs cas :
- Il ne fait rien : mouais, mais tu as demandé quelque chose, donc ce n'est pas la bonne solution
- Il fait un GET sur la page : pas mieux, GET et POST sont des actions différentes, non seulement il y a toutes les chances que le résultat soit différent de ce que tu attends mais ça a aussi toutes les chances de ne pas fonctionner voire de réaliser une action non souhaitée. Bref, il s'abstient.
- Il refait la même chose qu'avant, il renvoie les données : mais euh, tu es certain ? ça pourrait envoyer en double ton commentaire, déclencher deux suppressions, créer un doublon dans le système, déclencher une action couteuse alors que tu souhaitais simplement mettre à jour un résultat. Bref, pour éviter les problèmes le navigateur t'avertit avant (c'est chouette hein ? voilà pourquoi c'est un avertissement et pas une erreur).
Quand tu reviens en arrière la problématique est la même mais il a un choix en plus : renvoyer la page en cache.
Sauf que HTTP dit que le navigateur ne devrait pas mettre en cache les résultats d'un POST et qu'en plus le navigateur lui ne peut pas savoir si tu veux revenir en arrière avec le cache ou revoir la même action qu'avant (donc à jour). Bref, il choisit et t'avertit que la page a expiré (il ne met pas en cache) et donc qu'il va renvoyer les données, bref, te demande si tu es sûr de toi.
Après les navigateurs ont des heuristiques, parfois ils utilisent quand même un cache, ça dépend des contextes, de quand date ta visite précédente, et probablement d'autres paramètres.
Eventuellement, sur ton serveur, si tu veux forcer la mise en cache lors du retour arrière (ça ne changera rien à l'actualisation) ET que tu es conscient que ça risque de poser problème pour ceux qui veulent vraiment réaliser deux fois une action sur la même URL (et pas forcément via le retour arrière, peut être simplement poster deux commentaires différents), tu peux faire un cache-control:public, voire rajouter un max-age dans tes entêtes.
Sinon souvent ce qui est fait, c'est que le résultat du POST est simplement une redirection vers une autre page (qui elle sera en GET), vers laquelle tu peux revenir en arrière ou réactualiser sans problèmes (par contre si tu reviens en arrière un cran de plus tu retombes sur la page en POST avec le même problème)
Tu peux aussi t'amuser à envoyer ton POST en xhr pour que ça n'intefere pas avec l'historique du navigateur.
# mouais
Posté par Éric (site web personnel) . En réponse au message Warning : Page has expires. Évalué à 4.
Joie, c'est un avertissement (sisi, c'est marqué dedans).
Mieux, il est normal et souhaitable qu'on te le mette cet avertissement. Le problème serait plutôt que parfois on ne te le mette pas.
Alors voilà, quand tu fais un POST sur HTTP tu envoies des informations. Tu obtiens en retour un document qui résulte de cet envoi. Ca peut être par exemple un message de confirmation.
Que faire quand tu rafraichis la page ?
Il a plusieurs cas :
- Il ne fait rien : mouais, mais tu as demandé quelque chose, donc ce n'est pas la bonne solution
- Il fait un GET sur la page : pas mieux, GET et POST sont des actions différentes, non seulement il y a toutes les chances que le résultat soit différent de ce que tu attends mais ça a aussi toutes les chances de ne pas fonctionner voire de réaliser une action non souhaitée. Bref, il s'abstient.
- Il refait la même chose qu'avant, il renvoie les données : mais euh, tu es certain ? ça pourrait envoyer en double ton commentaire, déclencher deux suppressions, créer un doublon dans le système, déclencher une action couteuse alors que tu souhaitais simplement mettre à jour un résultat. Bref, pour éviter les problèmes le navigateur t'avertit avant (c'est chouette hein ? voilà pourquoi c'est un avertissement et pas une erreur).
Quand tu reviens en arrière la problématique est la même mais il a un choix en plus : renvoyer la page en cache.
Sauf que HTTP dit que le navigateur ne devrait pas mettre en cache les résultats d'un POST et qu'en plus le navigateur lui ne peut pas savoir si tu veux revenir en arrière avec le cache ou revoir la même action qu'avant (donc à jour). Bref, il choisit et t'avertit que la page a expiré (il ne met pas en cache) et donc qu'il va renvoyer les données, bref, te demande si tu es sûr de toi.
Après les navigateurs ont des heuristiques, parfois ils utilisent quand même un cache, ça dépend des contextes, de quand date ta visite précédente, et probablement d'autres paramètres.
Eventuellement, sur ton serveur, si tu veux forcer la mise en cache lors du retour arrière (ça ne changera rien à l'actualisation) ET que tu es conscient que ça risque de poser problème pour ceux qui veulent vraiment réaliser deux fois une action sur la même URL (et pas forcément via le retour arrière, peut être simplement poster deux commentaires différents), tu peux faire un cache-control:public, voire rajouter un max-age dans tes entêtes.
Sinon souvent ce qui est fait, c'est que le résultat du POST est simplement une redirection vers une autre page (qui elle sera en GET), vers laquelle tu peux revenir en arrière ou réactualiser sans problèmes (par contre si tu reviens en arrière un cran de plus tu retombes sur la page en POST avec le même problème)
Tu peux aussi t'amuser à envoyer ton POST en xhr pour que ça n'intefere pas avec l'historique du navigateur.