Si je me trompe faites le moi savoir:
La valeur du paramètre "Location" est une URL complete donc, il vaut mieux
remplacer(TRUE) que
ajouté(FALSE) sachant que par defaut on est sur FALSE ?
8 ans d'expérience ? Quelqu'un peut me rappeler la date de sortie de PHP/FI
siouplait ?
Yes sir :)
En premier lieu, il semble que Rasmus Lerdorf a annoncé publiquement l'existence du projet PHP (enfin, des PHP Tools) sur le comp.infosystems.www.authoring.cgi le 8 juin 1995.
http://groups.google.com/groups?selm=3r7pgp$
Ensuite, la version la plus ancienne, public et connue des sources de PHP dont nous disposons encore est la v1.99s. Une analyse du tag CVS du fichier main.c (ca me semble pas mal comme point de repère pour obtenir une date) donne ceci :
La suivante fût la v2.0 qui initia réellement la branche PHP/FI 2.0 (et uniquement après une série de beta release fort nombreuses). Une analyse similaire donne ceci :
/* $Id: main.c,v 1.59 1997/10/14 10:13:44 kara Exp $ */
Et ca tombe pile poil (on ne s'en étonnera pas) puisque PHP/FI 2.0 a été publiquement lancé en novembre 1997 (a rapprocher du 14 octobre 1997 au niveau du tag CVS).
Bref, pour avoir 8 ans d'expèrience en PHP aujourd'hui, ce n'est pas impossible, mais il faut avoir été vraiment précose. De mémoire et pour l'anecdote, cela remonte personnelement à décembre 1997. Je n'ai pas connu ni les PHP Tools, ni la branche 1.X.
HTH,
Armel.
8 ans d'expérience ? Quelqu'un peut me rappeler la date de sortie de
PHP/FI
siouplait ?
Yes sir :)
En premier lieu, il semble que Rasmus Lerdorf a annoncé publiquement
l'existence du projet PHP (enfin, des PHP Tools) sur le
comp.infosystems.www.authoring.cgi le 8 juin 1995.
Ensuite, la version la plus ancienne, public et connue des sources de PHP
dont nous disposons encore est la v1.99s. Une analyse du tag CVS du fichier
main.c (ca me semble pas mal comme point de repère pour obtenir une date)
donne ceci :
La suivante fût la v2.0 qui initia réellement la branche PHP/FI 2.0 (et
uniquement après une série de beta release fort nombreuses). Une analyse
similaire donne ceci :
/* $Id: main.c,v 1.59 1997/10/14 10:13:44 kara Exp $ */
Et ca tombe pile poil (on ne s'en étonnera pas) puisque PHP/FI 2.0 a été
publiquement lancé en novembre 1997 (a rapprocher du 14 octobre 1997 au
niveau du tag CVS).
Bref, pour avoir 8 ans d'expèrience en PHP aujourd'hui, ce n'est pas
impossible, mais il faut avoir été vraiment précose. De mémoire et pour
l'anecdote, cela remonte personnelement à décembre 1997. Je n'ai pas connu
ni les PHP Tools, ni la branche 1.X.
8 ans d'expérience ? Quelqu'un peut me rappeler la date de sortie de PHP/FI
siouplait ?
Yes sir :)
En premier lieu, il semble que Rasmus Lerdorf a annoncé publiquement l'existence du projet PHP (enfin, des PHP Tools) sur le comp.infosystems.www.authoring.cgi le 8 juin 1995.
http://groups.google.com/groups?selm=3r7pgp$
Ensuite, la version la plus ancienne, public et connue des sources de PHP dont nous disposons encore est la v1.99s. Une analyse du tag CVS du fichier main.c (ca me semble pas mal comme point de repère pour obtenir une date) donne ceci :
La suivante fût la v2.0 qui initia réellement la branche PHP/FI 2.0 (et uniquement après une série de beta release fort nombreuses). Une analyse similaire donne ceci :
/* $Id: main.c,v 1.59 1997/10/14 10:13:44 kara Exp $ */
Et ca tombe pile poil (on ne s'en étonnera pas) puisque PHP/FI 2.0 a été publiquement lancé en novembre 1997 (a rapprocher du 14 octobre 1997 au niveau du tag CVS).
Bref, pour avoir 8 ans d'expèrience en PHP aujourd'hui, ce n'est pas impossible, mais il faut avoir été vraiment précose. De mémoire et pour l'anecdote, cela remonte personnelement à décembre 1997. Je n'ai pas connu ni les PHP Tools, ni la branche 1.X.
HTH,
Armel.
CrazyCat
Savut wrote:
[snip]
Donc son usage est de terminer l'execution du script et si on veux, envoyer un message d'erreur au besoin. A noter aussi que exit() est a preferer. Aussi un simple note, exit() et die() devrait etre le plus souvent evite car cela fait des code assez patche, c'est a dire, avec certaine manque de control de condition, de verification d'erreur, etc... Sauf certaines cas... :D
Oui, sauf certains cas ou tu dois obligatoirement arréter ton script pour en attaquer un autre.
Aussi pour header(), j'ajouterai que header(location) sert a renvoyer le server sur une autre fichier, sans necessairement que ca sois du html, des images, des bin, etc. Par exemple j'ai ceci: [snip]
Revenons à la question de départ: la redirection de page!
Contrairement a ce que la plupart disent, Header("location: ../") marche, les url relative marchent.
Je n'ai jamais dis le contraire
Je pense avec mes 8 ans d'experiences en PHP d'etre en mesure de participer au debat.
Voir précédemment
Au fond, je ne dirais pas que ton code ne marche pas, mais c'est pas la bonne methode, et que dans certain utilisation plus specifique, ton die() pourrais te jouer de vilain tour.
Revoir le thème initial du thread
sont efficaces et stables ??? Etre efficace et stable c'est comprendre comment ca marche le language avant tout.
Faux, comment est structuré l'algorythme. Un bon analyste est capable de faire toute une application sur le papier sans la moindre connaissance d'un langage, les mot-clefs et les syntaxes sont dans les livres. Mais je présume que le fait que je programme allègrement en PHP, ASP, .NET fait que j'utilise des solutions communes qui ne sont pas forcémment plus optimisées pour tel ou tel langage mais efficace dans tous les cas.
Merci de ta conprehension. De rien
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Savut wrote:
[snip]
Donc son usage est de terminer l'execution du script et si on veux, envoyer
un message d'erreur au besoin.
A noter aussi que exit() est a preferer. Aussi un simple note, exit() et
die() devrait etre le plus souvent evite car cela fait des code assez
patche, c'est a dire, avec certaine manque de control de condition, de
verification d'erreur, etc... Sauf certaines cas... :D
Oui, sauf certains cas ou tu dois obligatoirement arréter ton script
pour en attaquer un autre.
Aussi pour header(), j'ajouterai que header(location) sert a renvoyer le
server sur une autre fichier, sans necessairement que ca sois du html, des
images, des bin, etc.
Par exemple j'ai ceci:
[snip]
Revenons à la question de départ: la redirection de page!
Contrairement a ce que la plupart disent, Header("location: ../") marche,
les url relative marchent.
Je n'ai jamais dis le contraire
Je pense avec mes 8 ans d'experiences en PHP d'etre en mesure de participer
au debat.
Voir précédemment
Au fond, je ne dirais pas que ton code ne marche pas, mais c'est pas la
bonne methode, et que dans certain utilisation plus specifique, ton die()
pourrais te jouer de vilain tour.
Revoir le thème initial du thread
sont efficaces et stables ??? Etre efficace et stable c'est comprendre
comment ca marche le language avant tout.
Faux, comment est structuré l'algorythme.
Un bon analyste est capable de faire toute une application sur le papier
sans la moindre connaissance d'un langage, les mot-clefs et les syntaxes
sont dans les livres.
Mais je présume que le fait que je programme allègrement en PHP, ASP,
.NET fait que j'utilise des solutions communes qui ne sont pas
forcémment plus optimisées pour tel ou tel langage mais efficace dans
tous les cas.
Merci de ta conprehension.
De rien
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
Donc son usage est de terminer l'execution du script et si on veux, envoyer un message d'erreur au besoin. A noter aussi que exit() est a preferer. Aussi un simple note, exit() et die() devrait etre le plus souvent evite car cela fait des code assez patche, c'est a dire, avec certaine manque de control de condition, de verification d'erreur, etc... Sauf certaines cas... :D
Oui, sauf certains cas ou tu dois obligatoirement arréter ton script pour en attaquer un autre.
Aussi pour header(), j'ajouterai que header(location) sert a renvoyer le server sur une autre fichier, sans necessairement que ca sois du html, des images, des bin, etc. Par exemple j'ai ceci: [snip]
Revenons à la question de départ: la redirection de page!
Contrairement a ce que la plupart disent, Header("location: ../") marche, les url relative marchent.
Je n'ai jamais dis le contraire
Je pense avec mes 8 ans d'experiences en PHP d'etre en mesure de participer au debat.
Voir précédemment
Au fond, je ne dirais pas que ton code ne marche pas, mais c'est pas la bonne methode, et que dans certain utilisation plus specifique, ton die() pourrais te jouer de vilain tour.
Revoir le thème initial du thread
sont efficaces et stables ??? Etre efficace et stable c'est comprendre comment ca marche le language avant tout.
Faux, comment est structuré l'algorythme. Un bon analyste est capable de faire toute une application sur le papier sans la moindre connaissance d'un langage, les mot-clefs et les syntaxes sont dans les livres. Mais je présume que le fait que je programme allègrement en PHP, ASP, .NET fait que j'utilise des solutions communes qui ne sont pas forcémment plus optimisées pour tel ou tel langage mais efficace dans tous les cas.
Merci de ta conprehension. De rien
-- Tout sur les eggdrops http://www.c-p-f.org ML @
CrazyCat
John Gallet wrote:
Il ne s'agit pas de PHP ou pas, mais d'algorithmique, c'est tout. qui je le rappelle est indépendante du langage. exit() est utilisée pour arrêter un script. Si l'algorithme que tu fais l'exige, tu utilises exit(). Point barre.
sont pas RFC compliant, sont efficaces et stables.
Ce qui veut donc dire que tes algoritmes sont corrects, ce qui est le plus important dans un programme informatique.
Merci :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
John Gallet wrote:
Il ne s'agit pas de PHP ou pas, mais d'algorithmique, c'est tout. qui je le
rappelle est indépendante du langage.
exit() est utilisée pour arrêter un script. Si l'algorithme que tu fais
l'exige, tu utilises exit(). Point barre.
sont pas RFC compliant, sont efficaces et stables.
Ce qui veut donc dire que tes algoritmes sont corrects, ce qui est le plus
important dans un programme informatique.
Merci :)
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
Il ne s'agit pas de PHP ou pas, mais d'algorithmique, c'est tout. qui je le rappelle est indépendante du langage. exit() est utilisée pour arrêter un script. Si l'algorithme que tu fais l'exige, tu utilises exit(). Point barre.
sont pas RFC compliant, sont efficaces et stables.
Ce qui veut donc dire que tes algoritmes sont corrects, ce qui est le plus important dans un programme informatique.
Merci :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
CrazyCat
Olivier Miakinen wrote:
Je voudrais bien te faire plaisir, mais non, je ne peux pas répondre par l'affirmative. Le header HTTP doit être reconnu par quiconque utilise HTTP pour récupérer des pages web. La balise META, au contraire, dépend de l'application qui aura récupéré la page, cherchera à l'interpréter, puis éventuellement décidera que c'est du HTML et que les caractères '<', 'M', 'E', 'T', 'A', etc., mis bout à bout, ont une signification et que cette signification fait qu'il pourrait être bon de laisser tomber la page en cours et de réouvrir une connexion HTTP pour faire une autre requête...
Ok, je pensais vraiment que <meta .....> pouvait être assimilé à des headers. Merci pour cette leçon :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Olivier Miakinen wrote:
Je voudrais bien te faire plaisir, mais non, je ne peux pas répondre par
l'affirmative. Le header HTTP doit être reconnu par quiconque utilise
HTTP pour récupérer des pages web. La balise META, au contraire, dépend
de l'application qui aura récupéré la page, cherchera à l'interpréter,
puis éventuellement décidera que c'est du HTML et que les caractères
'<', 'M', 'E', 'T', 'A', etc., mis bout à bout, ont une signification et
que cette signification fait qu'il pourrait être bon de laisser tomber
la page en cours et de réouvrir une connexion HTTP pour faire une autre
requête...
Ok, je pensais vraiment que <meta .....> pouvait être assimilé à des
headers.
Merci pour cette leçon :)
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
Je voudrais bien te faire plaisir, mais non, je ne peux pas répondre par l'affirmative. Le header HTTP doit être reconnu par quiconque utilise HTTP pour récupérer des pages web. La balise META, au contraire, dépend de l'application qui aura récupéré la page, cherchera à l'interpréter, puis éventuellement décidera que c'est du HTML et que les caractères '<', 'M', 'E', 'T', 'A', etc., mis bout à bout, ont une signification et que cette signification fait qu'il pourrait être bon de laisser tomber la page en cours et de réouvrir une connexion HTTP pour faire une autre requête...
Ok, je pensais vraiment que <meta .....> pouvait être assimilé à des headers. Merci pour cette leçon :)
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Eric Daspet
John Gallet wrote:
Pas dans son fonctionnement. C'est du HTML tout ce qu'il y a de plus correct et non une zone d'entêtes. Tu peux mettre du texte en dessous avec une valeur de refresh de quelques secondes, ce que header(Location) ne te permettra jamais de faire.
Oui, enfin là on compare deux choses non comparables. Il peut aussi faire une entête HTTP header("Refresh:...") de quelques secondes et mettre du contenu en dessous, ce que le meta de redirection simple ne pourra pas faire ;)
Tout ce qui est en <meta http-equiv="..."> peut passer en entête HTTP puisque le rôle de ce meta est justement de simuler des entêtes HTTP pour ceux qui ne peuvent pas en faire (fichiers HTML statiques par exemple). En PHP je ne vois que de très rares cas où un meta http-equiv est à préférer sur une entête HTTP.
-- Eric
John Gallet wrote:
Pas dans son fonctionnement. C'est du HTML tout ce qu'il y a de plus correct
et non une zone d'entêtes. Tu peux mettre du texte en dessous avec une
valeur de refresh de quelques secondes, ce que header(Location) ne te
permettra jamais de faire.
Oui, enfin là on compare deux choses non comparables. Il peut aussi
faire une entête HTTP header("Refresh:...") de quelques secondes et
mettre du contenu en dessous, ce que le meta de redirection simple ne
pourra pas faire ;)
Tout ce qui est en <meta http-equiv="..."> peut passer en entête HTTP
puisque le rôle de ce meta est justement de simuler des entêtes HTTP
pour ceux qui ne peuvent pas en faire (fichiers HTML statiques par
exemple). En PHP je ne vois que de très rares cas où un meta http-equiv
est à préférer sur une entête HTTP.
Pas dans son fonctionnement. C'est du HTML tout ce qu'il y a de plus correct et non une zone d'entêtes. Tu peux mettre du texte en dessous avec une valeur de refresh de quelques secondes, ce que header(Location) ne te permettra jamais de faire.
Oui, enfin là on compare deux choses non comparables. Il peut aussi faire une entête HTTP header("Refresh:...") de quelques secondes et mettre du contenu en dessous, ce que le meta de redirection simple ne pourra pas faire ;)
Tout ce qui est en <meta http-equiv="..."> peut passer en entête HTTP puisque le rôle de ce meta est justement de simuler des entêtes HTTP pour ceux qui ne peuvent pas en faire (fichiers HTML statiques par exemple). En PHP je ne vois que de très rares cas où un meta http-equiv est à préférer sur une entête HTTP.
-- Eric
Eric Daspet
Olivier Miakinen wrote:
ÀMHA, l'avantage principal de l'entête HTTP sur la balise META, c'est que cela fonctionne aussi bien pour les binaires (par exemple les images) que pour les pages HTML. Un autre avantage, c'est que si le visiteur passe par un proxy, eh bien le proxy redemandera la page correcte tout seul comme un grand, au lieu de remonter la page HTML puis d'attendre une nouvelle requête.
C'est faux si tu utilises juste header('Location: .....'); Dans ce cas PHP envoie un code de redirection temporaire (302 à mon souvenir) et les caches sont tenus de ne pas retenir cette redirection (à savoir si les navigateurs s'y conforment ou pas c'est autre chose, mais logiquement les caches devraient gérer ça correctement et ne retenir que les contenus). Si tu veux que les caches (proxy et navigateur) retiennent cette info il faudra aussi rajouter header('Moved permanently', TRUE, 301) afin de signaler une redirection permanente.
-- Eric
Olivier Miakinen wrote:
ÀMHA, l'avantage principal de l'entête HTTP sur la balise META, c'est
que cela fonctionne aussi bien pour les binaires (par exemple les
images) que pour les pages HTML. Un autre avantage, c'est que si le
visiteur passe par un proxy, eh bien le proxy redemandera la page
correcte tout seul comme un grand, au lieu de remonter la page HTML puis
d'attendre une nouvelle requête.
C'est faux si tu utilises juste header('Location: .....');
Dans ce cas PHP envoie un code de redirection temporaire (302 à mon
souvenir) et les caches sont tenus de ne pas retenir cette redirection
(à savoir si les navigateurs s'y conforment ou pas c'est autre chose,
mais logiquement les caches devraient gérer ça correctement et ne
retenir que les contenus).
Si tu veux que les caches (proxy et navigateur) retiennent cette info il
faudra aussi rajouter header('Moved permanently', TRUE, 301) afin de
signaler une redirection permanente.
ÀMHA, l'avantage principal de l'entête HTTP sur la balise META, c'est que cela fonctionne aussi bien pour les binaires (par exemple les images) que pour les pages HTML. Un autre avantage, c'est que si le visiteur passe par un proxy, eh bien le proxy redemandera la page correcte tout seul comme un grand, au lieu de remonter la page HTML puis d'attendre une nouvelle requête.
C'est faux si tu utilises juste header('Location: .....'); Dans ce cas PHP envoie un code de redirection temporaire (302 à mon souvenir) et les caches sont tenus de ne pas retenir cette redirection (à savoir si les navigateurs s'y conforment ou pas c'est autre chose, mais logiquement les caches devraient gérer ça correctement et ne retenir que les contenus). Si tu veux que les caches (proxy et navigateur) retiennent cette info il faudra aussi rajouter header('Moved permanently', TRUE, 301) afin de signaler une redirection permanente.
-- Eric
Eric Daspet
Savut wrote:
Contrairement a ce que la plupart disent, Header("location: ../") marche, les url relative marchent.
Oui, mais tu oublies une partie importante dans la phrase : Elles marchent *pour les implémentations HTTP les plus courantes dans les navigateurs*.
Si je ne m'abuse, dans les RFC seules des URL absolues sont censées être mises. Des relatives *peuvent* marcher mais du coup rien n'est garanti, et si c'est autre chose qu'un navigateur classique qui gêre la requête, perso je ne garantirai rien.
De plus, tu peux très bien utiliser une url relative avec ce meta.
Et c'est la même chose avec le méta puisque le méta http-equiv consiste juste à dire au navigateur "fais comme si tu avais l'entête HTTP X avec le contenu Y. Les règles de contenu, leur rôle et leur interprétation sont strictement les mêmes (du moins pour un navigateur interprétant les meta HTML).
-- Eric
Savut wrote:
Contrairement a ce que la plupart disent, Header("location: ../") marche,
les url relative marchent.
Oui, mais tu oublies une partie importante dans la phrase : Elles
marchent *pour les implémentations HTTP les plus courantes dans les
navigateurs*.
Si je ne m'abuse, dans les RFC seules des URL absolues sont censées être
mises. Des relatives *peuvent* marcher mais du coup rien n'est garanti,
et si c'est autre chose qu'un navigateur classique qui gêre la requête,
perso je ne garantirai rien.
De plus, tu peux très bien utiliser une url relative avec ce meta.
Et c'est la même chose avec le méta puisque le méta http-equiv consiste
juste à dire au navigateur "fais comme si tu avais l'entête HTTP X avec
le contenu Y. Les règles de contenu, leur rôle et leur interprétation
sont strictement les mêmes (du moins pour un navigateur interprétant les
meta HTML).
Contrairement a ce que la plupart disent, Header("location: ../") marche, les url relative marchent.
Oui, mais tu oublies une partie importante dans la phrase : Elles marchent *pour les implémentations HTTP les plus courantes dans les navigateurs*.
Si je ne m'abuse, dans les RFC seules des URL absolues sont censées être mises. Des relatives *peuvent* marcher mais du coup rien n'est garanti, et si c'est autre chose qu'un navigateur classique qui gêre la requête, perso je ne garantirai rien.
De plus, tu peux très bien utiliser une url relative avec ce meta.
Et c'est la même chose avec le méta puisque le méta http-equiv consiste juste à dire au navigateur "fais comme si tu avais l'entête HTTP X avec le contenu Y. Les règles de contenu, leur rôle et leur interprétation sont strictement les mêmes (du moins pour un navigateur interprétant les meta HTML).
