Mais même dans ce cas là tu devrais commencer par regarder le code HTML
généré (View/Page source) car il y a sûrement des choses à voir.
En quelques mots, le header("Location: ...") ne devrais jamais servir à
rien d'autre qu'à rediriger d'un site vers un autres, et pas entre deux
pages du même site.
D'ailleurs il devrait toujours y avoir une URL
absolue (du genre http://www.example.com/test.html) et jamais une URL
relative (telle que test.html).
Mais même dans ce cas là tu devrais commencer par regarder le code HTML
généré (View/Page source) car il y a sûrement des choses à voir.
En quelques mots, le header("Location: ...") ne devrais jamais servir à
rien d'autre qu'à rediriger d'un site vers un autres, et pas entre deux
pages du même site.
D'ailleurs il devrait toujours y avoir une URL
absolue (du genre http://www.example.com/test.html) et jamais une URL
relative (telle que test.html).
Mais même dans ce cas là tu devrais commencer par regarder le code HTML
généré (View/Page source) car il y a sûrement des choses à voir.
En quelques mots, le header("Location: ...") ne devrais jamais servir à
rien d'autre qu'à rediriger d'un site vers un autres, et pas entre deux
pages du même site.
D'ailleurs il devrait toujours y avoir une URL
absolue (du genre http://www.example.com/test.html) et jamais une URL
relative (telle que test.html).
Bonjour,
En gros, on bouffe quand même deux fois l'intégralité des ressources.
Marrant quand même que ça ne gêne personne, une perte en ressources de
100%... alors qu'ensuite on va voir les mêmes (pas toi Bruno) nous
rabâcher les oreilles que echo va plus ou moins vite que print et que
parser ''.$foo.'' va plus ou moins vite que "$foo"... pour gagner 10e-3
ou 10e-4% de perfs.
J'ajouterai aussi des effets de bord à la con, par exemple le fait que
ça force un GET (ce qui en soit n'a pas d'importance mais par exemple un
Location:....php?donnee_confidentielle«c sera écrit dans les logs
http). Voire la création inutile d'un process de plus pour gérer la
requête parce que pas assez de spare.
Ce qui me gêne le plus étant le nombre affolant de cas où on a:
a.php
[verifications diverses, c'est bien]
[si tout va bien : Location...b.php]
[sinon Location:... error.php]
avec dans b.php
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
C'est une MALC qui parlera peut-être plus (ou moins) que celle des
livreurs de machine à laver, mais c'est similaire. Au lieu d'exécuter
directement dès la première requête http la bonne routine (procédurale
ou OO, là n'est pas la question, via require ou non, la n'est pas la
question) on va passer par un intermédiaire, distant (le client) pour
lui demander d'appeler le bon code avec les bons arguments. Moi je
trouve ça complètement délirant *dans le principe même* sur un même
serveur/environnement sur un même protocole. Si on passe de http à
https, pas le choix, si on redirige vers un autre environnement
inaccessible localement, peu de choix ou méthodes similaires de toutes
façons (genre xml-rpc).
Comme toujours, l'essentiel est de comprendre les avantages et
inconvénients de chaque méthode. Je suis parfaitement d'accord sur le
fait qu'on peut en avoir deux ou trois qui traînent, mais le vrai danger
commence quand on l'élève en méthode standard de programmation pour tout
sans en comprendre les impacts.
JG
Bonjour,
En gros, on bouffe quand même deux fois l'intégralité des ressources.
Marrant quand même que ça ne gêne personne, une perte en ressources de
100%... alors qu'ensuite on va voir les mêmes (pas toi Bruno) nous
rabâcher les oreilles que echo va plus ou moins vite que print et que
parser ''.$foo.'' va plus ou moins vite que "$foo"... pour gagner 10e-3
ou 10e-4% de perfs.
J'ajouterai aussi des effets de bord à la con, par exemple le fait que
ça force un GET (ce qui en soit n'a pas d'importance mais par exemple un
Location:....php?donnee_confidentielle«c sera écrit dans les logs
http). Voire la création inutile d'un process de plus pour gérer la
requête parce que pas assez de spare.
Ce qui me gêne le plus étant le nombre affolant de cas où on a:
a.php
[verifications diverses, c'est bien]
[si tout va bien : Location...b.php]
[sinon Location:... error.php]
avec dans b.php
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
C'est une MALC qui parlera peut-être plus (ou moins) que celle des
livreurs de machine à laver, mais c'est similaire. Au lieu d'exécuter
directement dès la première requête http la bonne routine (procédurale
ou OO, là n'est pas la question, via require ou non, la n'est pas la
question) on va passer par un intermédiaire, distant (le client) pour
lui demander d'appeler le bon code avec les bons arguments. Moi je
trouve ça complètement délirant *dans le principe même* sur un même
serveur/environnement sur un même protocole. Si on passe de http à
https, pas le choix, si on redirige vers un autre environnement
inaccessible localement, peu de choix ou méthodes similaires de toutes
façons (genre xml-rpc).
Comme toujours, l'essentiel est de comprendre les avantages et
inconvénients de chaque méthode. Je suis parfaitement d'accord sur le
fait qu'on peut en avoir deux ou trois qui traînent, mais le vrai danger
commence quand on l'élève en méthode standard de programmation pour tout
sans en comprendre les impacts.
JG
Bonjour,
En gros, on bouffe quand même deux fois l'intégralité des ressources.
Marrant quand même que ça ne gêne personne, une perte en ressources de
100%... alors qu'ensuite on va voir les mêmes (pas toi Bruno) nous
rabâcher les oreilles que echo va plus ou moins vite que print et que
parser ''.$foo.'' va plus ou moins vite que "$foo"... pour gagner 10e-3
ou 10e-4% de perfs.
J'ajouterai aussi des effets de bord à la con, par exemple le fait que
ça force un GET (ce qui en soit n'a pas d'importance mais par exemple un
Location:....php?donnee_confidentielle«c sera écrit dans les logs
http). Voire la création inutile d'un process de plus pour gérer la
requête parce que pas assez de spare.
Ce qui me gêne le plus étant le nombre affolant de cas où on a:
a.php
[verifications diverses, c'est bien]
[si tout va bien : Location...b.php]
[sinon Location:... error.php]
avec dans b.php
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
C'est une MALC qui parlera peut-être plus (ou moins) que celle des
livreurs de machine à laver, mais c'est similaire. Au lieu d'exécuter
directement dès la première requête http la bonne routine (procédurale
ou OO, là n'est pas la question, via require ou non, la n'est pas la
question) on va passer par un intermédiaire, distant (le client) pour
lui demander d'appeler le bon code avec les bons arguments. Moi je
trouve ça complètement délirant *dans le principe même* sur un même
serveur/environnement sur un même protocole. Si on passe de http à
https, pas le choix, si on redirige vers un autre environnement
inaccessible localement, peu de choix ou méthodes similaires de toutes
façons (genre xml-rpc).
Comme toujours, l'essentiel est de comprendre les avantages et
inconvénients de chaque méthode. Je suis parfaitement d'accord sur le
fait qu'on peut en avoir deux ou trois qui traînent, mais le vrai danger
commence quand on l'élève en méthode standard de programmation pour tout
sans en comprendre les impacts.
JG
Votre approche ne prend pas du tout en compte la notion des URI.
C'est parfaitement exact, et là n'est pas mon propos.
rare). L'association *ressource*-*emplacement* permet de gagner
significativement en termes de performances puisqu'elle facilite la mise
en cache des données
en page. Il est donc faux de prétendre qu'on "bouffe" deux fois
l'intégralité des ressources.
Si la conception est bien faite, on utilisera toutes les ressources
nécessaires à la génération au premier appel, puis on utilisera les
traitements mis en cache, ce qui est parfaitement économe.
Les effets de bords que vous mentionnez sont aussi provoqués par une
mauvaise conception.
J'ai pas dit le contraire. Je ne fais que signaler la situation que je
D'une part, si rien ne vous empêche de placer des données confidentielle
dans une requête GET (sauf peut-être la CNIL dans certains cas les plus
grave et si on lui rapporte l'abus), la méthode n'est pas prévue pour et
entre en conflit avec la sécurité du service et des informations
personnelles.
Là n'est pas la question. Si on n'écrit pas ces informations dans les
Utilisation de services spécialisés, pas de transmission de données
personnelles en clair.
J'admet que cette procédure peut être coûteuse, mais elle n'intervient
que pour l'identification du client (assez rarement donc)
Rarement ? Juste sur chaque page demandée pour vérifier les droits
Quand à l'argument de processus créé, que dites vous de ceux qui sont
créés pour générer des pages existantes dans le cache de l'utilisateur,
Cf RFC2616
Je l'ai dit et je le redis: je me tamponne complètement de ce qu'il est
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Problème de conception, encore.
Je n'ai pas dit le contraire.
Si on ne doit pas utiliser une fonctionnalité parce qu'un groupe de
personne ne sait pas l'utiliser, on
n'utilisera plus rien de notre existence.
Je n'ai pas dit le contraire. Le vrai problème c'est que à élever
Ce genre de phénomène n'est donc pas à prendre en compte dans le
développement.
Vous parlez de qui par "phénomène(s)" ? ;-) La théorisation et
Si vous ne souhaitez pas le faire, pas de soucis, mais abstenez vous de
la propagande.
Je vous renvoie le compliment: si vous vous estimez suffisement maître de
Pour la résolution du problème mentionné, cf RFC2616 10.4.4 403 Forbidden
ROTFL ! La page b.php est nécessairement publique !
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
Ca dépend entièrement du contexte... Là n'était pas, d'après moi, le
thème et il serait tout aussi idiot de *toujours appeler directement*.
Contexte: n'importe quelle application en C/C++/Java fonctionnant sur une
Les deux actions rediriger et inclure on un sens profondément différent.
Dans le premier cas, on dit "Je ne m'occupe pas de ça, va voir là-bas.",
Non, pas "vas voir là-bas", justement. Vas voir là-bas, c'est juste passer
dans le second, on dit "Oui, je suis habilité à exécuter cette procédure,
un instant s'il vous plaît."
Ou tout simplement : je passer le bébé à celui qui est habilité.
Je ne comprends pas votre point de vue,
Oui ça je l'avais compris.
et encore moins quelle est la situation délirante. Le principe
client/serveur sert à alléger une machinerie lourde.
Euh... Là ça frise le ridicule. Vous parlez de ce qu'on fait avec un
Et votre histoire de livreur, je la trouve bien tirée
par les cheveux et vous n'avez même pas remarqué que dans le cas d'un
"include" mal utilisé, votre livreur va percer un trou dans le mur du
voisin chez qui il a sonné pour accéder à l'appartement du voisin chez
qui il devrait livré, sans prendre la peine d'aller sonner à sa porte.
Un conception, c'est une planification: on ne doit pas procéder dans le
désordre ou alors on fait mal, on perd du temps, des ressources, on
bafoue les règles de courtoisie...
Votre approche ne prend pas du tout en compte la notion des URI.
C'est parfaitement exact, et là n'est pas mon propos.
rare). L'association *ressource*-*emplacement* permet de gagner
significativement en termes de performances puisqu'elle facilite la mise
en cache des données
en page. Il est donc faux de prétendre qu'on "bouffe" deux fois
l'intégralité des ressources.
Si la conception est bien faite, on utilisera toutes les ressources
nécessaires à la génération au premier appel, puis on utilisera les
traitements mis en cache, ce qui est parfaitement économe.
Les effets de bords que vous mentionnez sont aussi provoqués par une
mauvaise conception.
J'ai pas dit le contraire. Je ne fais que signaler la situation que je
D'une part, si rien ne vous empêche de placer des données confidentielle
dans une requête GET (sauf peut-être la CNIL dans certains cas les plus
grave et si on lui rapporte l'abus), la méthode n'est pas prévue pour et
entre en conflit avec la sécurité du service et des informations
personnelles.
Là n'est pas la question. Si on n'écrit pas ces informations dans les
Utilisation de services spécialisés, pas de transmission de données
personnelles en clair.
J'admet que cette procédure peut être coûteuse, mais elle n'intervient
que pour l'identification du client (assez rarement donc)
Rarement ? Juste sur chaque page demandée pour vérifier les droits
Quand à l'argument de processus créé, que dites vous de ceux qui sont
créés pour générer des pages existantes dans le cache de l'utilisateur,
Cf RFC2616
Je l'ai dit et je le redis: je me tamponne complètement de ce qu'il est
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Problème de conception, encore.
Je n'ai pas dit le contraire.
Si on ne doit pas utiliser une fonctionnalité parce qu'un groupe de
personne ne sait pas l'utiliser, on
n'utilisera plus rien de notre existence.
Je n'ai pas dit le contraire. Le vrai problème c'est que à élever
Ce genre de phénomène n'est donc pas à prendre en compte dans le
développement.
Vous parlez de qui par "phénomène(s)" ? ;-) La théorisation et
Si vous ne souhaitez pas le faire, pas de soucis, mais abstenez vous de
la propagande.
Je vous renvoie le compliment: si vous vous estimez suffisement maître de
Pour la résolution du problème mentionné, cf RFC2616 10.4.4 403 Forbidden
ROTFL ! La page b.php est nécessairement publique !
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
Ca dépend entièrement du contexte... Là n'était pas, d'après moi, le
thème et il serait tout aussi idiot de *toujours appeler directement*.
Contexte: n'importe quelle application en C/C++/Java fonctionnant sur une
Les deux actions rediriger et inclure on un sens profondément différent.
Dans le premier cas, on dit "Je ne m'occupe pas de ça, va voir là-bas.",
Non, pas "vas voir là-bas", justement. Vas voir là-bas, c'est juste passer
dans le second, on dit "Oui, je suis habilité à exécuter cette procédure,
un instant s'il vous plaît."
Ou tout simplement : je passer le bébé à celui qui est habilité.
Je ne comprends pas votre point de vue,
Oui ça je l'avais compris.
et encore moins quelle est la situation délirante. Le principe
client/serveur sert à alléger une machinerie lourde.
Euh... Là ça frise le ridicule. Vous parlez de ce qu'on fait avec un
Et votre histoire de livreur, je la trouve bien tirée
par les cheveux et vous n'avez même pas remarqué que dans le cas d'un
"include" mal utilisé, votre livreur va percer un trou dans le mur du
voisin chez qui il a sonné pour accéder à l'appartement du voisin chez
qui il devrait livré, sans prendre la peine d'aller sonner à sa porte.
Un conception, c'est une planification: on ne doit pas procéder dans le
désordre ou alors on fait mal, on perd du temps, des ressources, on
bafoue les règles de courtoisie...
Votre approche ne prend pas du tout en compte la notion des URI.
C'est parfaitement exact, et là n'est pas mon propos.
rare). L'association *ressource*-*emplacement* permet de gagner
significativement en termes de performances puisqu'elle facilite la mise
en cache des données
en page. Il est donc faux de prétendre qu'on "bouffe" deux fois
l'intégralité des ressources.
Si la conception est bien faite, on utilisera toutes les ressources
nécessaires à la génération au premier appel, puis on utilisera les
traitements mis en cache, ce qui est parfaitement économe.
Les effets de bords que vous mentionnez sont aussi provoqués par une
mauvaise conception.
J'ai pas dit le contraire. Je ne fais que signaler la situation que je
D'une part, si rien ne vous empêche de placer des données confidentielle
dans une requête GET (sauf peut-être la CNIL dans certains cas les plus
grave et si on lui rapporte l'abus), la méthode n'est pas prévue pour et
entre en conflit avec la sécurité du service et des informations
personnelles.
Là n'est pas la question. Si on n'écrit pas ces informations dans les
Utilisation de services spécialisés, pas de transmission de données
personnelles en clair.
J'admet que cette procédure peut être coûteuse, mais elle n'intervient
que pour l'identification du client (assez rarement donc)
Rarement ? Juste sur chaque page demandée pour vérifier les droits
Quand à l'argument de processus créé, que dites vous de ceux qui sont
créés pour générer des pages existantes dans le cache de l'utilisateur,
Cf RFC2616
Je l'ai dit et je le redis: je me tamponne complètement de ce qu'il est
[aucune verification, vas-y mon gars, je reçois n'importe quoi j'y vais]
Problème de conception, encore.
Je n'ai pas dit le contraire.
Si on ne doit pas utiliser une fonctionnalité parce qu'un groupe de
personne ne sait pas l'utiliser, on
n'utilisera plus rien de notre existence.
Je n'ai pas dit le contraire. Le vrai problème c'est que à élever
Ce genre de phénomène n'est donc pas à prendre en compte dans le
développement.
Vous parlez de qui par "phénomène(s)" ? ;-) La théorisation et
Si vous ne souhaitez pas le faire, pas de soucis, mais abstenez vous de
la propagande.
Je vous renvoie le compliment: si vous vous estimez suffisement maître de
Pour la résolution du problème mentionné, cf RFC2616 10.4.4 403 Forbidden
ROTFL ! La page b.php est nécessairement publique !
Moi ce qui me gêne surtout, c'est qu'il serait quand même assez tordu de
ne *jamais appeler directement la méthode d'un objet* et de
systématiquement passer par deux autres objets dans deux threads séparés
qui ferait cet appel après sérialisation.
Ca dépend entièrement du contexte... Là n'était pas, d'après moi, le
thème et il serait tout aussi idiot de *toujours appeler directement*.
Contexte: n'importe quelle application en C/C++/Java fonctionnant sur une
Les deux actions rediriger et inclure on un sens profondément différent.
Dans le premier cas, on dit "Je ne m'occupe pas de ça, va voir là-bas.",
Non, pas "vas voir là-bas", justement. Vas voir là-bas, c'est juste passer
dans le second, on dit "Oui, je suis habilité à exécuter cette procédure,
un instant s'il vous plaît."
Ou tout simplement : je passer le bébé à celui qui est habilité.
Je ne comprends pas votre point de vue,
Oui ça je l'avais compris.
et encore moins quelle est la situation délirante. Le principe
client/serveur sert à alléger une machinerie lourde.
Euh... Là ça frise le ridicule. Vous parlez de ce qu'on fait avec un
Et votre histoire de livreur, je la trouve bien tirée
par les cheveux et vous n'avez même pas remarqué que dans le cas d'un
"include" mal utilisé, votre livreur va percer un trou dans le mur du
voisin chez qui il a sonné pour accéder à l'appartement du voisin chez
qui il devrait livré, sans prendre la peine d'aller sonner à sa porte.
Un conception, c'est une planification: on ne doit pas procéder dans le
désordre ou alors on fait mal, on perd du temps, des ressources, on
bafoue les règles de courtoisie...