Bonjour, je cherche une solution pour faire un addslashes systématiquement
si le système hôte n'a pas l'option magic_quotes_gpc activée (et donc que
les données provenants d'un POST/GET/COOKIE sont livrées telles quelles)
Tous les accès aux variables GET ou POST de mon application passent par
cette méthode :
function getRequestParam($paramName)
{
global $HTTP_SERVER_VARS;
if (!get_magic_quotes_gpc())
$result = addslashes($result);
return $result;
}
Et malgré tout, sur le système de production (FreeBSD PHP 4.3.10 en CGI),
j'obtiens des erreurs lorsqu'une quote est insérée dans un champ de
formulaire.
Par ailleurs, je précise que j'utilise toujours la syntaxe suivante dans
mes requêtes SQL :
nom_de_champ_db = '$valeur_du_champ'
Je veux dire par là que je mets la valeur du champs elle même entre ''
Ben voilà. Ça s'applique au navigateur et au système de cache parce que, contrairement au serveur, ils ne peuvent pas deviner si les données ont été rafraîchies depuis la dernière requête.
Si ton système de cache en PHP se trouve directement en frontal de ton application ( ce qui est le plus efficace en terme de temps de réponse ), celui-ci ne peut pas non plus deviner que les données ont changé. Une méthode est donc de tout simplement d'appliquer la règle donnée par le W3C.
Dans le fichier de conf, on décrit les quelques exeptions.
Ce qui nous donne: - si la requête fait partie des exceptions, on examine la règle et on décide de ce qu'on doit faire - si la requête est GET et qu'elle ne figure pas dans la liste des exceptions, on prend le cache - si la requête est POST et qu'elle ne figure pas dans la règle des exceptions, on transmet la requête à l'appli
C'est une application possible de la différenciation entre les requêtes POST et GET. C'est aussi réalisable avec $_REQUEST mais beaucoup plus lourd à gérer.
La première chose à faire, *côté serveur*, c'est de détecter quand les données changent, et d'indiquer (la « stipulation contraire ») cet état dans les réponses HTTP, et ce, que l'on passe par GET ou par POST.
Je suis d'accord pour indiquer le Last-Modified ( même si celui-ci ne sert pas à grand chose puisque la page va quand même être servie et transiter sur le réseau jusqu'au premier proxy ) et le ETag, par contre pour Cache-Control: max-age=xxx et Expires, on est pas devin, c'est inapplicable dans la plupart des cas, sauf quand les données sont mises à jour à heure fixe. C'est comme les systèmes de cache qui implémentent un système de timeout alors qu'il est si simple que ce soit le script chargé des mises à jours qui prévienne qu'il faut regénérer le cache.
Il ne faut pas non plus oublier de dire quand les données n'ont pas changé ( code 304 ) en réponse à un If-modified-since.
Et pour savoir si les données ont changé ou non, il faut déjà avoir un système de cache ( enfin si ton application est un peu complexe et qu'elle met en oeuvre différentes zones dans la même page qui on des durées de vie différentes )
Ben voilà. Ça s'applique au navigateur et au système de cache parce que,
contrairement au serveur, ils ne peuvent pas deviner si les données ont
été rafraîchies depuis la dernière requête.
Si ton système de cache en PHP se trouve directement en frontal de ton
application ( ce qui est le plus efficace en terme de temps de réponse
), celui-ci ne peut pas non plus deviner que les données ont changé. Une
méthode est donc de tout simplement d'appliquer la règle donnée par le W3C.
Dans le fichier de conf, on décrit les quelques exeptions.
Ce qui nous donne:
- si la requête fait partie des exceptions, on examine la règle et on
décide de ce qu'on doit faire
- si la requête est GET et qu'elle ne figure pas dans la liste des
exceptions, on prend le cache
- si la requête est POST et qu'elle ne figure pas dans la règle des
exceptions, on transmet la requête à l'appli
C'est une application possible de la différenciation entre les requêtes
POST et GET. C'est aussi réalisable avec $_REQUEST mais beaucoup plus
lourd à gérer.
La première chose à faire, *côté serveur*, c'est de détecter quand les
données changent, et d'indiquer (la « stipulation contraire ») cet état
dans les réponses HTTP, et ce, que l'on passe par GET ou par POST.
Je suis d'accord pour indiquer le Last-Modified ( même si celui-ci ne
sert pas à grand chose puisque la page va quand même être servie et
transiter sur le réseau jusqu'au premier proxy ) et le ETag, par contre
pour Cache-Control: max-age=xxx et Expires, on est pas devin, c'est
inapplicable dans la plupart des cas, sauf quand les données sont mises
à jour à heure fixe. C'est comme les systèmes de cache qui implémentent
un système de timeout alors qu'il est si simple que ce soit le script
chargé des mises à jours qui prévienne qu'il faut regénérer le cache.
Il ne faut pas non plus oublier de dire quand les données n'ont pas
changé ( code 304 ) en réponse à un If-modified-since.
Et pour savoir si les données ont changé ou non, il faut déjà avoir un
système de cache ( enfin si ton application est un peu complexe et
qu'elle met en oeuvre différentes zones dans la même page qui on des
durées de vie différentes )
Ben voilà. Ça s'applique au navigateur et au système de cache parce que, contrairement au serveur, ils ne peuvent pas deviner si les données ont été rafraîchies depuis la dernière requête.
Si ton système de cache en PHP se trouve directement en frontal de ton application ( ce qui est le plus efficace en terme de temps de réponse ), celui-ci ne peut pas non plus deviner que les données ont changé. Une méthode est donc de tout simplement d'appliquer la règle donnée par le W3C.
Dans le fichier de conf, on décrit les quelques exeptions.
Ce qui nous donne: - si la requête fait partie des exceptions, on examine la règle et on décide de ce qu'on doit faire - si la requête est GET et qu'elle ne figure pas dans la liste des exceptions, on prend le cache - si la requête est POST et qu'elle ne figure pas dans la règle des exceptions, on transmet la requête à l'appli
C'est une application possible de la différenciation entre les requêtes POST et GET. C'est aussi réalisable avec $_REQUEST mais beaucoup plus lourd à gérer.
La première chose à faire, *côté serveur*, c'est de détecter quand les données changent, et d'indiquer (la « stipulation contraire ») cet état dans les réponses HTTP, et ce, que l'on passe par GET ou par POST.
Je suis d'accord pour indiquer le Last-Modified ( même si celui-ci ne sert pas à grand chose puisque la page va quand même être servie et transiter sur le réseau jusqu'au premier proxy ) et le ETag, par contre pour Cache-Control: max-age=xxx et Expires, on est pas devin, c'est inapplicable dans la plupart des cas, sauf quand les données sont mises à jour à heure fixe. C'est comme les systèmes de cache qui implémentent un système de timeout alors qu'il est si simple que ce soit le script chargé des mises à jours qui prévienne qu'il faut regénérer le cache.
Il ne faut pas non plus oublier de dire quand les données n'ont pas changé ( code 304 ) en réponse à un If-modified-since.
Et pour savoir si les données ont changé ou non, il faut déjà avoir un système de cache ( enfin si ton application est un peu complexe et qu'elle met en oeuvre différentes zones dans la même page qui on des durées de vie différentes )
Zouplaz
loufoque wrote in news:431edd4a$0$11337$:
magic_quotes_gpc est une abomination, tu devrais plutôt faire en sorte de le désactiver. Ça a été créé pour empêcher que les débutants se prennent des failles, un site pro ne devrait surtout pas l'utiliser...
Je ne m'en sert pas mais je suis obligé de faire en sorte que mes applis fonctionnent dans tous les cas...
Ce n'est pas POST/GET/Cookie qu'il faut échapper, ce sont les chaînes que tu insères dans une requête. Ces chaînes ne sont pas forcément POST/GET/Cookie, et il se peut que tu veuilles utiliser les variables POST/GET/Cookie pour autre chose que créer des requêtes.
Oui mais dans ma réalité ces cas ne se présentent jamais avec des données textuelles (toutes les données textuelles proviennent uniquement de formulaires). Et de la même façon, toutes les données que je manipule sont stockées dans des bases de données, je n'en ai pas d'autre utilisation pour l'instant et je n'ai aucune envie de me mettre à élaborer des solutions pour des répondres à des besoins qui ne sont pas les miens.
Maintenant si tu as une solution élégante pour n'échapper que les chaines destinées aux requêtes :
- sans risque d'oubli - sans augmenter le nombre de ligne de code par 2 - portable d'un environnement à un autre
Je suis preneur !!!
loufoque <loufoque@remove.gmail.com> wrote in
news:431edd4a$0$11337$626a14ce@news.free.fr:
magic_quotes_gpc est une abomination, tu devrais plutôt faire en sorte
de le désactiver.
Ça a été créé pour empêcher que les débutants se prennent des failles,
un site pro ne devrait surtout pas l'utiliser...
Je ne m'en sert pas mais je suis obligé de faire en sorte que mes applis
fonctionnent dans tous les cas...
Ce n'est pas POST/GET/Cookie qu'il faut échapper, ce sont les chaînes
que tu insères dans une requête.
Ces chaînes ne sont pas forcément POST/GET/Cookie, et il se peut que
tu veuilles utiliser les variables POST/GET/Cookie pour autre chose
que créer des requêtes.
Oui mais dans ma réalité ces cas ne se présentent jamais avec des données
textuelles (toutes les données textuelles proviennent uniquement de
formulaires).
Et de la même façon, toutes les données que je manipule sont stockées dans
des bases de données, je n'en ai pas d'autre utilisation pour l'instant et
je n'ai aucune envie de me mettre à élaborer des solutions pour des
répondres à des besoins qui ne sont pas les miens.
Maintenant si tu as une solution élégante pour n'échapper que les chaines
destinées aux requêtes :
- sans risque d'oubli
- sans augmenter le nombre de ligne de code par 2
- portable d'un environnement à un autre
magic_quotes_gpc est une abomination, tu devrais plutôt faire en sorte de le désactiver. Ça a été créé pour empêcher que les débutants se prennent des failles, un site pro ne devrait surtout pas l'utiliser...
Je ne m'en sert pas mais je suis obligé de faire en sorte que mes applis fonctionnent dans tous les cas...
Ce n'est pas POST/GET/Cookie qu'il faut échapper, ce sont les chaînes que tu insères dans une requête. Ces chaînes ne sont pas forcément POST/GET/Cookie, et il se peut que tu veuilles utiliser les variables POST/GET/Cookie pour autre chose que créer des requêtes.
Oui mais dans ma réalité ces cas ne se présentent jamais avec des données textuelles (toutes les données textuelles proviennent uniquement de formulaires). Et de la même façon, toutes les données que je manipule sont stockées dans des bases de données, je n'en ai pas d'autre utilisation pour l'instant et je n'ai aucune envie de me mettre à élaborer des solutions pour des répondres à des besoins qui ne sont pas les miens.
Maintenant si tu as une solution élégante pour n'échapper que les chaines destinées aux requêtes :
- sans risque d'oubli - sans augmenter le nombre de ligne de code par 2 - portable d'un environnement à un autre
Je suis preneur !!!
John GALLET
Re,
Dans la norme HTTP il est stipulé que les données GET sont mises en cache par défaut sauf stipulation contraire et que les données POST ne sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Cette règle s'applique au navigateur et systèmes de cache. Ca j'en ai rien à battre. La première chose que je vais faire si j'ai un
site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne pas, le problème est résolu, ça veut dire que de toutes façons rien ne marchera correctement.
Moi je parle d'un cache html de requêtes côté serveur.Pas du cache local sur le disque dur de chaque client.
Si tu mettais la requête en GET, tu bénéficierais du cache du navigateur et de celui des proxy,
Je n'en veux SURTOUT PAS. Comment pourrais-je les dévalider quand je sais que je fais une modification ?
la première chose à faire est donc de passer les requêtes en GET avant de vouloir implémenter un cache en PHP. La première chose à faire est surtout de se mettre d'accord de quoi on
cause.
En ce qui me concerne, c'est exclusivement de l'utilité de la différenciation des méthodes get et post ***côté serveur*** dans le cadre du développement d'une webapp (en php,jsp, cobol-objet, etc... peu importe).
décision quand à la politique générale et on se retrouve avec une liste phénoménale d'exceptions difficiles à maintenir Pas du tout, il suffit que chaque ressource (que tu appelels
probablement URI) connaisse son propre comportement. Une approche objet quelque part.
a++; JG
Re,
Dans la norme HTTP il est stipulé que les données GET sont mises en
cache par défaut sauf stipulation contraire et que les données POST ne
sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Cette règle s'applique au navigateur et systèmes de cache.
Ca j'en ai rien à battre. La première chose que je vais faire si j'ai un
site dynamique c'est coller un pragma no-cache en espérant qu'il
fonctionne. S'il fonctionne pas, le problème est résolu, ça veut dire
que de toutes façons rien ne marchera correctement.
Moi je parle d'un cache html de requêtes côté serveur.Pas du cache local
sur le disque dur de chaque client.
Si tu mettais la requête en GET, tu bénéficierais du cache du navigateur
et de celui des proxy,
Je n'en veux SURTOUT PAS. Comment pourrais-je les dévalider quand je
sais que je fais une modification ?
la première chose à faire est donc de passer les
requêtes en GET avant de vouloir implémenter un cache en PHP.
La première chose à faire est surtout de se mettre d'accord de quoi on
cause.
En ce qui me concerne, c'est exclusivement de l'utilité de la
différenciation des méthodes get et post ***côté serveur*** dans le
cadre du développement d'une webapp (en php,jsp, cobol-objet, etc... peu
importe).
décision quand à la politique générale et on se retrouve avec une liste
phénoménale d'exceptions difficiles à maintenir
Pas du tout, il suffit que chaque ressource (que tu appelels
probablement URI) connaisse son propre comportement. Une approche objet
quelque part.
Dans la norme HTTP il est stipulé que les données GET sont mises en cache par défaut sauf stipulation contraire et que les données POST ne sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Cette règle s'applique au navigateur et systèmes de cache. Ca j'en ai rien à battre. La première chose que je vais faire si j'ai un
site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne pas, le problème est résolu, ça veut dire que de toutes façons rien ne marchera correctement.
Moi je parle d'un cache html de requêtes côté serveur.Pas du cache local sur le disque dur de chaque client.
Si tu mettais la requête en GET, tu bénéficierais du cache du navigateur et de celui des proxy,
Je n'en veux SURTOUT PAS. Comment pourrais-je les dévalider quand je sais que je fais une modification ?
la première chose à faire est donc de passer les requêtes en GET avant de vouloir implémenter un cache en PHP. La première chose à faire est surtout de se mettre d'accord de quoi on
cause.
En ce qui me concerne, c'est exclusivement de l'utilité de la différenciation des méthodes get et post ***côté serveur*** dans le cadre du développement d'une webapp (en php,jsp, cobol-objet, etc... peu importe).
décision quand à la politique générale et on se retrouve avec une liste phénoménale d'exceptions difficiles à maintenir Pas du tout, il suffit que chaque ressource (que tu appelels
probablement URI) connaisse son propre comportement. Une approche objet quelque part.
a++; JG
ftc
Re,
Dans la norme HTTP il est stipulé que les données GET sont mises en cache par défaut sauf stipulation contraire et que les données POST ne sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Si, on parle du même cache, le cache de page HTML, mais avant de mettre des pages en cache, il faut connaitre le comportement du navigateur et des serveur proxy pour savoir si une page sera redemander ou non.
La première chose que je vais faire si j'ai un site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne >pas, le problème est résolu, ça veut dire que de toutes
façons rien ne >marchera correctement.
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0. Si le serveur est compatible HTTP/1.1, il y a une floppée d'headers que l'on peut utiliser pour gérer la mise en cache côté client et pragma est sans doute la pire.
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son précdent message: http://www.mnot.net/cache_docs/ )
décision quand à la politique générale et on se retrouve avec une liste phénoménale d'exceptions difficiles à maintenir
Pas du tout, il suffit que chaque ressource (que tu appelels probablement URI) connaisse son propre comportement. Une approche objet quelque part.
Ben on parle bien du même cache, mais pas de la même façonde l'implémenter. Dans ton système, chaque ressource gère sont propre cache. Moi je décris un cache global qui prend la main avant l'appli et qui doit prendre des décisions sans demander quoi que ce soit à l'appli, pas la peine d'instancier une floppée de classes si c'est la version en cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose. L'application prévient juste quand tel ou tel cache est devenu invalide.
Re,
Dans la norme HTTP il est stipulé que les données GET sont mises en
cache par défaut sauf stipulation contraire et que les données POST ne
sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Si, on parle du même cache, le cache de page HTML, mais avant de mettre
des pages en cache, il faut connaitre le comportement du navigateur et
des serveur proxy pour savoir si une page sera redemander ou non.
La première chose que je vais faire si j'ai un site dynamique c'est
coller un pragma no-cache en espérant qu'il fonctionne. S'il
fonctionne >pas, le problème est résolu, ça veut dire que de toutes
façons rien ne >marchera correctement.
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies
l'implémentent, il date de l'époque de HTTP/1.0. Si le serveur est
compatible HTTP/1.1, il y a une floppée d'headers que l'on peut utiliser
pour gérer la mise en cache côté client et pragma est sans doute la pire.
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son
précdent message: http://www.mnot.net/cache_docs/ )
décision quand à la politique générale et on se retrouve avec une
liste phénoménale d'exceptions difficiles à maintenir
Pas du tout, il suffit que chaque ressource (que tu appelels
probablement URI) connaisse son propre comportement. Une approche objet
quelque part.
Ben on parle bien du même cache, mais pas de la même façonde
l'implémenter. Dans ton système, chaque ressource gère sont propre
cache. Moi je décris un cache global qui prend la main avant l'appli et
qui doit prendre des décisions sans demander quoi que ce soit à l'appli,
pas la peine d'instancier une floppée de classes si c'est la version en
cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose.
L'application prévient juste quand tel ou tel cache est devenu invalide.
Dans la norme HTTP il est stipulé que les données GET sont mises en cache par défaut sauf stipulation contraire et que les données POST ne sont pas mises en cache sauf stipulation contraire.
On parle pas du même cache toi et moi.
Si, on parle du même cache, le cache de page HTML, mais avant de mettre des pages en cache, il faut connaitre le comportement du navigateur et des serveur proxy pour savoir si une page sera redemander ou non.
La première chose que je vais faire si j'ai un site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne >pas, le problème est résolu, ça veut dire que de toutes
façons rien ne >marchera correctement.
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0. Si le serveur est compatible HTTP/1.1, il y a une floppée d'headers que l'on peut utiliser pour gérer la mise en cache côté client et pragma est sans doute la pire.
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son précdent message: http://www.mnot.net/cache_docs/ )
décision quand à la politique générale et on se retrouve avec une liste phénoménale d'exceptions difficiles à maintenir
Pas du tout, il suffit que chaque ressource (que tu appelels probablement URI) connaisse son propre comportement. Une approche objet quelque part.
Ben on parle bien du même cache, mais pas de la même façonde l'implémenter. Dans ton système, chaque ressource gère sont propre cache. Moi je décris un cache global qui prend la main avant l'appli et qui doit prendre des décisions sans demander quoi que ce soit à l'appli, pas la peine d'instancier une floppée de classes si c'est la version en cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose. L'application prévient juste quand tel ou tel cache est devenu invalide.
John GALLET
Re,
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation me semble exagérée car je n'ai jamais rencontré de problèmes en l'utilisant. J'ai pas assez de chance pour systématiquement toujours être tombé sur les soit disant rares implémentations de cette directive...
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son précdent message: http://www.mnot.net/cache_docs/ )
Ce document nous parle comme d'habitude des beaux standards et non de la manière dont ils sont réellement implémentés (ce qui a le don de m'agacer, si seulement toutes les applications largement diffusées pouvait une bonne fois pour toutes respecter ces #@*! de normes, ça irait mieux, mais c'est pas comme ça dans la vraie vie). Enfin bref, on rajoutera le bidule qu'ils indiquent, ça doit pas pouvoir faire de mal.
qui doit prendre des décisions sans demander quoi que ce soit à l'appli, pas la peine d'instancier une floppée de classes si c'est la version en cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose.
Qui a parlé d'instancier des classes pour rien ? Déjà ce sera exécuter des procédures en ce qui me concerne, ensuite pour vérifier si le cache est valide ou non, ça cache^Wcasse pas trois pattes à un pingouin.
Maintenant personnellement je préfère gérer un cache au niveau SQL, c'est donc plus bas de toutes façons.
L'application prévient juste quand tel ou tel cache est devenu invalide. Oui dans tous les cas.
a++; JG
Re,
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies
l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation
me semble exagérée car je n'ai jamais rencontré de problèmes en
l'utilisant. J'ai pas assez de chance pour systématiquement toujours être
tombé sur les soit disant rares implémentations de cette directive...
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son
précdent message: http://www.mnot.net/cache_docs/ )
Ce document nous parle comme d'habitude des beaux standards et non de la
manière dont ils sont réellement implémentés (ce qui a le don de m'agacer,
si seulement toutes les applications largement diffusées pouvait une bonne
fois pour toutes respecter ces #@*! de normes, ça irait mieux, mais c'est
pas comme ça dans la vraie vie). Enfin bref, on rajoutera le bidule qu'ils
indiquent, ça doit pas pouvoir faire de mal.
qui doit prendre des décisions sans demander quoi que ce soit à l'appli,
pas la peine d'instancier une floppée de classes si c'est la version en
cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose.
Qui a parlé d'instancier des classes pour rien ? Déjà ce sera exécuter des
procédures en ce qui me concerne, ensuite pour vérifier si le cache est
valide ou non, ça cache^Wcasse pas trois pattes à un pingouin.
Maintenant personnellement je préfère gérer un cache au niveau SQL, c'est
donc plus bas de toutes façons.
L'application prévient juste quand tel ou tel cache est devenu invalide.
Oui dans tous les cas.
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation me semble exagérée car je n'ai jamais rencontré de problèmes en l'utilisant. J'ai pas assez de chance pour systématiquement toujours être tombé sur les soit disant rares implémentations de cette directive...
(cf: spécification HTTP/1.1 et doc donnée par Olivier Miakinen dans son précdent message: http://www.mnot.net/cache_docs/ )
Ce document nous parle comme d'habitude des beaux standards et non de la manière dont ils sont réellement implémentés (ce qui a le don de m'agacer, si seulement toutes les applications largement diffusées pouvait une bonne fois pour toutes respecter ces #@*! de normes, ça irait mieux, mais c'est pas comme ça dans la vraie vie). Enfin bref, on rajoutera le bidule qu'ils indiquent, ça doit pas pouvoir faire de mal.
qui doit prendre des décisions sans demander quoi que ce soit à l'appli, pas la peine d'instancier une floppée de classes si c'est la version en cache qui doit être utilisée sinon celui-ci ne sert plus à grand chose.
Qui a parlé d'instancier des classes pour rien ? Déjà ce sera exécuter des procédures en ce qui me concerne, ensuite pour vérifier si le cache est valide ou non, ça cache^Wcasse pas trois pattes à un pingouin.
Maintenant personnellement je préfère gérer un cache au niveau SQL, c'est donc plus bas de toutes façons.
L'application prévient juste quand tel ou tel cache est devenu invalide. Oui dans tous les cas.
a++; JG
ftc
Re,
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation me semble exagérée car je n'ai jamais rencontré de problèmes en l'utilisant. J'ai pas assez de chance pour systématiquement toujours être tombé sur les soit disant rares implémentations de cette directive...
Ah bon, pourtant dans le mail précédent tu dis: "si j'ai un site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne pas, le problème est résolu, ça veut dire que de toutes façons rien ne marchera correctement."
C'est donc que tu as déjà rencontré des problèmes avec cet header. Personellement, je ne l'utilise jamais et gère le cache avec les header prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le header Etag.
Re,
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies
l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation
me semble exagérée car je n'ai jamais rencontré de problèmes en
l'utilisant. J'ai pas assez de chance pour systématiquement toujours être
tombé sur les soit disant rares implémentations de cette directive...
Ah bon, pourtant dans le mail précédent tu dis:
"si j'ai un site dynamique c'est coller un pragma no-cache en espérant
qu'il fonctionne. S'il fonctionne pas, le problème est résolu, ça veut
dire que de toutes façons rien ne marchera correctement."
C'est donc que tu as déjà rencontré des problèmes avec cet header.
Personellement, je ne l'utilise jamais et gère le cache avec les header
prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le
header Etag.
"Pragma: no-cache" est totalement inutile, peu de navigateurs et proxies l'implémentent, il date de l'époque de HTTP/1.0.
J'en prends bonne note, en notant aussi au passage que cette affirmation me semble exagérée car je n'ai jamais rencontré de problèmes en l'utilisant. J'ai pas assez de chance pour systématiquement toujours être tombé sur les soit disant rares implémentations de cette directive...
Ah bon, pourtant dans le mail précédent tu dis: "si j'ai un site dynamique c'est coller un pragma no-cache en espérant qu'il fonctionne. S'il fonctionne pas, le problème est résolu, ça veut dire que de toutes façons rien ne marchera correctement."
C'est donc que tu as déjà rencontré des problèmes avec cet header. Personellement, je ne l'utilise jamais et gère le cache avec les header prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le header Etag.
John GALLET
Re,
C'est donc que tu as déjà rencontré des problèmes avec cet header.
Non, ça veut simplement dire que je sais pertinement que les navig'ta-soeur ont chacun leur comportement propre plus ou moins proche des soit-disants standards et que j'admets (à tord ?) que la proportion de ces saloperies ne comprenant pas ce pragma est négligeable donc que j'exclue volontairement les contrevenants s'ils existent parce que je n'en ai jamais rencontré depuis 1996 (plus précisement 1999 parce que je n'ai peut-être pas eut besoin d'employer ce pragma avant). Et je le précise parce que je suis le premier à casser les c... de tout le monde avec la rétro-compatibilité, donc il est rarissime que je tienne ce discours.
Personellement, je ne l'utilise jamais et gère le cache avec les header prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le header Etag.
Une fois de plus, j'en prends bonne note, s'il y a des choses normées/standardisées et soit-disant plus implémentées que d'autres, je les utiliserai.
a++; JG -- La dictature, c'est "Ferme ta gueule". La démocratie, c'est "Cause toujours".
Re,
C'est donc que tu as déjà rencontré des problèmes avec cet header.
Non, ça veut simplement dire que je sais pertinement que les
navig'ta-soeur ont chacun leur comportement propre plus ou moins proche
des soit-disants standards et que j'admets (à tord ?) que la proportion
de ces saloperies ne comprenant pas ce pragma est négligeable donc que
j'exclue volontairement les contrevenants s'ils existent parce que je
n'en ai jamais rencontré depuis 1996 (plus précisement 1999 parce que je
n'ai peut-être pas eut besoin d'employer ce pragma avant). Et je le
précise parce que je suis le premier à casser les c... de tout le monde
avec la rétro-compatibilité, donc il est rarissime que je tienne ce
discours.
Personellement, je ne l'utilise jamais et gère le cache avec les header
prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le
header Etag.
Une fois de plus, j'en prends bonne note, s'il y a des choses
normées/standardisées et soit-disant plus implémentées que d'autres, je
les utiliserai.
a++;
JG
--
La dictature, c'est "Ferme ta gueule".
La démocratie, c'est "Cause toujours".
C'est donc que tu as déjà rencontré des problèmes avec cet header.
Non, ça veut simplement dire que je sais pertinement que les navig'ta-soeur ont chacun leur comportement propre plus ou moins proche des soit-disants standards et que j'admets (à tord ?) que la proportion de ces saloperies ne comprenant pas ce pragma est négligeable donc que j'exclue volontairement les contrevenants s'ils existent parce que je n'en ai jamais rencontré depuis 1996 (plus précisement 1999 parce que je n'ai peut-être pas eut besoin d'employer ce pragma avant). Et je le précise parce que je suis le premier à casser les c... de tout le monde avec la rétro-compatibilité, donc il est rarissime que je tienne ce discours.
Personellement, je ne l'utilise jamais et gère le cache avec les header prévu pour HTTP/1.1 et je n'ai jamais eu de problèmes, notament le header Etag.
Une fois de plus, j'en prends bonne note, s'il y a des choses normées/standardisées et soit-disant plus implémentées que d'autres, je les utiliserai.
a++; JG -- La dictature, c'est "Ferme ta gueule". La démocratie, c'est "Cause toujours".
