Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting.
Un petit problème amusant comment émuler les URL rewriting en PHP pour
un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même :
1) d'obtenir de ton hébergeur qu'il le propose ;
2) s'il ne veut pas, de changer d'hébergeur ;
3) si tu ne veux pas, de te passer d'URL rewriting.
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting.
YeT
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting.
4) en attendant mettre dans l'url un truc du genre : www.site.com?url=photos/YeT/14/12/2007
YeT (même pas peur)
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour
un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même :
1) d'obtenir de ton hébergeur qu'il le propose ;
2) s'il ne veut pas, de changer d'hébergeur ;
3) si tu ne veux pas, de te passer d'URL rewriting.
4) en attendant mettre dans l'url un truc du genre :
www.site.com?url=photos/YeT/14/12/2007
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting.
4) en attendant mettre dans l'url un truc du genre : www.site.com?url=photos/YeT/14/12/2007
YeT (même pas peur)
BertrandB
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting. oui certainement en utilisant les pages d'erreur 404 et 403.
3) je n'en ai pas réellement besoin c'est pour le fun 2) j'en suis à 3 hébergeurs + pages perso de mon Fai donc si c'était bloquant j'hebergerais au bon endroit 1) Dans l'idée je cible l'offre Demo1G d'OVH qui est gratuite ils ont désactivé tout ce qui peut être source potentiel de problème, s'ils n'ont pas activé les url rewriting ils ont certainement de bonnes raisons.
Un petit problème amusant comment émuler les URL rewriting en PHP pour
un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même :
1) d'obtenir de ton hébergeur qu'il le propose ;
2) s'il ne veut pas, de changer d'hébergeur ;
3) si tu ne veux pas, de te passer d'URL rewriting.
oui certainement en utilisant les pages d'erreur 404 et 403.
3) je n'en ai pas réellement besoin c'est pour le fun
2) j'en suis à 3 hébergeurs + pages perso de mon Fai donc si c'était
bloquant j'hebergerais au bon endroit
1) Dans l'idée je cible l'offre Demo1G d'OVH qui est gratuite ils ont
désactivé tout ce qui peut être source potentiel de problème, s'ils
n'ont pas activé les url rewriting ils ont certainement de bonnes raisons.
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Mais le mieux serait quand même : 1) d'obtenir de ton hébergeur qu'il le propose ; 2) s'il ne veut pas, de changer d'hébergeur ; 3) si tu ne veux pas, de te passer d'URL rewriting. oui certainement en utilisant les pages d'erreur 404 et 403.
3) je n'en ai pas réellement besoin c'est pour le fun 2) j'en suis à 3 hébergeurs + pages perso de mon Fai donc si c'était bloquant j'hebergerais au bon endroit 1) Dans l'idée je cible l'offre Demo1G d'OVH qui est gratuite ils ont désactivé tout ce qui peut être source potentiel de problème, s'ils n'ont pas activé les url rewriting ils ont certainement de bonnes raisons.
YeT
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
YeT
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour
un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
YeT
BertrandB
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ? Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
YeT pour les query string pas vraiment de problème a priori mais les donées
en POST je ne sais pas.
"Olivier Miakinen"
Un petit problème amusant comment émuler les URL rewriting en PHP pour
un hébergement qui ne le propose pas ?
Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
YeT
pour les query string pas vraiment de problème a priori mais les donées
Un petit problème amusant comment émuler les URL rewriting en PHP pour un hébergement qui ne le propose pas ? Peut-être avec « ErrorDocument 404 /404.php » dans le .htaccess, puis
une page 404.php qui redirige vers la bonne page en fonction de l'URI.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
YeT pour les query string pas vraiment de problème a priori mais les donées
en POST je ne sais pas.
Olivier Miakinen
[ émuler les URL rewriting ]
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est fournir une URL plus facile à mémoriser par l'utilisateur qui doit la saisir dans son navigateur. Le second, c'est pour rediriger une ancienne URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée lors de la soumission d'un formulaire.
Alors je ne sais pas si les variables $_GET ou $_POST se perdent en cas d'erreur 404, mais je ne pense pas que ce soit très gênant.
[ émuler les URL rewriting ]
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est
fournir une URL plus facile à mémoriser par l'utilisateur qui doit la
saisir dans son navigateur. Le second, c'est pour rediriger une ancienne
URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une
nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée
lors de la soumission d'un formulaire.
Alors je ne sais pas si les variables $_GET ou $_POST se perdent en cas
d'erreur 404, mais je ne pense pas que ce soit très gênant.
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est fournir une URL plus facile à mémoriser par l'utilisateur qui doit la saisir dans son navigateur. Le second, c'est pour rediriger une ancienne URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée lors de la soumission d'un formulaire.
Alors je ne sais pas si les variables $_GET ou $_POST se perdent en cas d'erreur 404, mais je ne pense pas que ce soit très gênant.
YeT
En fait j'avais essayé une seule page index.php (appelé aussi par les erreurs 404) à la racine du site avec des require(s) suivant le contenu de l'url et donc forcement parfois des formulaires, je perdais les variables POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne trouvais pas cette solution très esthétique :-)
YeT
En fait j'avais essayé une seule page index.php (appelé aussi par les
erreurs 404) à la racine du site avec des require(s) suivant le contenu de
l'url et donc forcement parfois des formulaires, je perdais les variables
POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne
trouvais pas cette solution très esthétique :-)
En fait j'avais essayé une seule page index.php (appelé aussi par les erreurs 404) à la racine du site avec des require(s) suivant le contenu de l'url et donc forcement parfois des formulaires, je perdais les variables POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne trouvais pas cette solution très esthétique :-)
YeT
BertrandB
En fait j'avais essayé une seule page index.php (appelé aussi par les erreurs 404) à la racine du site avec des require(s) suivant le contenu de l'url et donc forcement parfois des formulaires, je perdais les variables POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne trouvais pas cette solution très esthétique :-)
YeT L'idée c'est de ne pas utiliser include() ou require() mais virtual()
Des premiers tests sur ovh on récupère bien la query string donc donc ça devrait faire. http://fr2.php.net/manual/fr/function.virtual.php
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les URL dans le cas de passage de parammètre par GET et non pas POST. Dans le lien au dessus il y a des 'trucs' pour les POST
En fait j'avais essayé une seule page index.php (appelé aussi par les
erreurs 404) à la racine du site avec des require(s) suivant le contenu de
l'url et donc forcement parfois des formulaires, je perdais les variables
POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne
trouvais pas cette solution très esthétique :-)
YeT
L'idée c'est de ne pas utiliser include() ou require() mais virtual()
Des premiers tests sur ovh on récupère bien la query string donc donc ça
devrait faire.
http://fr2.php.net/manual/fr/function.virtual.php
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les
URL dans le cas de passage de parammètre par GET et non pas POST. Dans
le lien au dessus il y a des 'trucs' pour les POST
En fait j'avais essayé une seule page index.php (appelé aussi par les erreurs 404) à la racine du site avec des require(s) suivant le contenu de l'url et donc forcement parfois des formulaires, je perdais les variables POST ...
J'ai abandonné ne sachant pas d'où cela venait et aussi parce que je ne trouvais pas cette solution très esthétique :-)
YeT L'idée c'est de ne pas utiliser include() ou require() mais virtual()
Des premiers tests sur ovh on récupère bien la query string donc donc ça devrait faire. http://fr2.php.net/manual/fr/function.virtual.php
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les URL dans le cas de passage de parammètre par GET et non pas POST. Dans le lien au dessus il y a des 'trucs' pour les POST
BertrandB
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les URL dans le cas de passage de parammètre par GET et non pas POST. Dans le lien au dessus il y a des 'trucs' pour les POST
Et à ce propos j'ai trouvé une discussion surle frum de zazou mini web server une discussion intéressante.
Avec Apache et PHP n peut simlifier les URl sans URL rewriting en utilisant multiviews et pathinfo. Sous demo1G je n'ai pas réussi à activer le multiviews. Si vous voulez tester : http://belguise.ovh.org/phpinfo.php/truc/machin/bidule?lang=etranger
si le multiviews fonctionnait on aurait pu écrire http://belguise.ovh.org/phpinfo/truc/machin/bidule?lang=etranger
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les
URL dans le cas de passage de parammètre par GET et non pas POST. Dans
le lien au dessus il y a des 'trucs' pour les POST
Et à ce propos j'ai trouvé une discussion surle frum de zazou mini web
server une discussion intéressante.
Avec Apache et PHP n peut simlifier les URl sans URL rewriting en
utilisant multiviews et pathinfo.
Sous demo1G je n'ai pas réussi à activer le multiviews. Si vous voulez
tester :
http://belguise.ovh.org/phpinfo.php/truc/machin/bidule?lang=etranger
si le multiviews fonctionnait on aurait pu écrire
http://belguise.ovh.org/phpinfo/truc/machin/bidule?lang=etranger
Mais comme dit Olivier en général l'URLrewriting sert à simplifier les URL dans le cas de passage de parammètre par GET et non pas POST. Dans le lien au dessus il y a des 'trucs' pour les POST
Et à ce propos j'ai trouvé une discussion surle frum de zazou mini web server une discussion intéressante.
Avec Apache et PHP n peut simlifier les URl sans URL rewriting en utilisant multiviews et pathinfo. Sous demo1G je n'ai pas réussi à activer le multiviews. Si vous voulez tester : http://belguise.ovh.org/phpinfo.php/truc/machin/bidule?lang=etranger
si le multiviews fonctionnait on aurait pu écrire http://belguise.ovh.org/phpinfo/truc/machin/bidule?lang=etranger
Patrick 'Zener' Brunet
Bonjour.
"Olivier Miakinen" <om+ a écrit dans le message de news: 4763e7e4$
[ émuler les URL rewriting ]
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est fournir une URL plus facile à mémoriser par l'utilisateur qui doit la saisir dans son navigateur.
Le second, c'est pour rediriger une ancienne URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée lors de la soumission d'un formulaire.
J'utilise l'URL rewriting systématiquement sur mon site www.ipzb.fr pour une autre raison: Ce site utilise systématiquement un master script qui va chercher tous les composants de la page dans l'arborescence, pour plusieurs raisons: - pour gérer la sécurité et le contexte (paramètres d'accessibilité) du visiteur en général, - pour éviter les problèmes de base quand on entre en HTTP par un sous-répertoire, - parce que chaque page est une combinaison de paramètres: son ID, sa langue...
Donc au début il y avait un get.php suivi d'au moins 4 arguments, et c'est pas recommandé pour être correctement indexé (dixit le manuel). Il y a même eu des robots qui zappaient les arguments et martelaient le pauvre get.php, à ce stade ça devient dangereux pour le serveur.
J'ai observé aussi que ça a l'air de poser des problèmes aux validateurs du W3C par exemple.
Donc l'URL rewriting me permet de présenter une URL à l'apparence statique qui intègre les arguments fondamentaux (définissant la page), les autres arguments restant dans la query string.
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Bonjour.
"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
4763e7e4$1@neottia.net...
[ émuler les URL rewriting ]
Il n'y a pas un problème avec les variables des formulaires qui se
perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est
fournir une URL plus facile à mémoriser par l'utilisateur qui doit la
saisir dans son navigateur.
Le second, c'est pour rediriger une ancienne
URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une
nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée
lors de la soumission d'un formulaire.
J'utilise l'URL rewriting systématiquement sur mon site www.ipzb.fr pour une
autre raison:
Ce site utilise systématiquement un master script qui va chercher tous les
composants de la page dans l'arborescence, pour plusieurs raisons:
- pour gérer la sécurité et le contexte (paramètres d'accessibilité) du
visiteur en général,
- pour éviter les problèmes de base quand on entre en HTTP par un
sous-répertoire,
- parce que chaque page est une combinaison de paramètres: son ID, sa
langue...
Donc au début il y avait un get.php suivi d'au moins 4 arguments, et c'est
pas recommandé pour être correctement indexé (dixit le manuel). Il y a même
eu des robots qui zappaient les arguments et martelaient le pauvre get.php,
à ce stade ça devient dangereux pour le serveur.
J'ai observé aussi que ça a l'air de poser des problèmes aux validateurs du
W3C par exemple.
Donc l'URL rewriting me permet de présenter une URL à l'apparence statique
qui intègre les arguments fondamentaux (définissant la page), les autres
arguments restant dans la query string.
--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/
"Olivier Miakinen" <om+ a écrit dans le message de news: 4763e7e4$
[ émuler les URL rewriting ]
Il n'y a pas un problème avec les variables des formulaires qui se perdent ?
Je vois deux cas où l'URL rewriting peut être utile. Le premier, c'est fournir une URL plus facile à mémoriser par l'utilisateur qui doit la saisir dans son navigateur.
Le second, c'est pour rediriger une ancienne URL (qui peut avoir été mise en signet ou transmise à un tiers) vers une nouvelle URL. Aucun de ces deux cas ne correspond à une page appelée lors de la soumission d'un formulaire.
J'utilise l'URL rewriting systématiquement sur mon site www.ipzb.fr pour une autre raison: Ce site utilise systématiquement un master script qui va chercher tous les composants de la page dans l'arborescence, pour plusieurs raisons: - pour gérer la sécurité et le contexte (paramètres d'accessibilité) du visiteur en général, - pour éviter les problèmes de base quand on entre en HTTP par un sous-répertoire, - parce que chaque page est une combinaison de paramètres: son ID, sa langue...
Donc au début il y avait un get.php suivi d'au moins 4 arguments, et c'est pas recommandé pour être correctement indexé (dixit le manuel). Il y a même eu des robots qui zappaient les arguments et martelaient le pauvre get.php, à ce stade ça devient dangereux pour le serveur.
J'ai observé aussi que ça a l'air de poser des problèmes aux validateurs du W3C par exemple.
Donc l'URL rewriting me permet de présenter une URL à l'apparence statique qui intègre les arguments fondamentaux (définissant la page), les autres arguments restant dans la query string.
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
