SOS debutant : bloque sur header location

(snip)

<OP>
Outre ton problème effectif (

Désolé, pas fait le ménage avant de poster...

(snip)

Non, il est dans le cas de figure d'une redirection après un login. Que
la redirection soit ou non la meilleure solution dans ce cas est une
question ouverte - et à laquelle il n'y a probablement pas de réponse
absolue puisque ça dépend aussi de l'architecture applicative. En tout
état de cause, ce n'est AMHA pas une raison (bien au contraire) pour lui
présenter comme vérité d'évangile un avis personnel qui contredit le
standard.

Pour ma part, je n'ais toujours pas compris pourquoi ce serait si mal,
comme je le lit si souvent sur ce newsgroup, d'utiliser un header
location apres un login (surtout que apres avoir lu la RFC, et toutes
les doc la dessus, je n'ai rien trouvé de consistant qui aurrais put
l'expliquer), donc j'irrais plutot dans le sens de Bruno.

Que l'adresse soit absolut : oui
Que l'on utilise pas le header location entres deux pages d'un meme
domaine : pourquoi se priver et se casser la tête à trouver des solution
de remplacement quand on a un outil tres bien qui marche du tonnere !

Olivier Miakinen wrote:

(snip)

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.

Chapitre et verset, s'il te plait ?

« La vie trépidante des livreurs de machine à laver », par John Gallet.

Quelques numéros de chapitre et verset se trouvent ici :
http://groups.google.fr/groups/search?q=livreur+author%3AGallet

Bonjour Monsieur

Question qui se pose (durement) pour moi (mon site, voir signature):

Sur mon site, je me sers abondamment des header("Location: ") pour
rediriger de scripts vers un autre script.

Ces redirections, sont uniquement ( et strictement ) destinées à
m'affranchir de la limitation imposée par l'hébergeur ( je suis en mutu,
nul n'est parfait... ), quant au délai limite d'exécution d'un script
PHP ( 22 secondes pour l'hébergeur Sivit, ce qui est très peu... ).

Les durées d'exécution de mes scripts, en une seule transaction, sont
bien supérieures à 22 secondes, de l'ordre parfois ( rarement je
l'admet... ) de une minute, en tout cas, il m'est strictement impossible
de faire autre chose que des redirections, ne serait-ce que pour les
erreurs, justement pour dépassement de délai, synchronisation de
processus concurrents, etc... )

Vous me direz: les include( ) font celà. Oui, mais quand on inclut un
script dans un autre, le script incluant les autres scripts, est soumis
à cette limitation de 22 secondes... Pas faisable donc.

En d'autres termes, qu'y a-t-il de plus logique, pour s'affranchir de
la limitation de délai, que de procéder en faisant plusieurs requêtes
HTTP ?

Or, poursuivre un même processus en faisant plusieurs requêtes HTTP,
ce n'est possible qu'avec header...

Si vous avez d'autres solutions pour ce problème de délai, que les
header, merci beaucoup de me le dire, je serais très très heureux de
faire une programmation "dans les normes", surtout que j'ai déjà lu
quelques écrits de Monsieur John Gallet, qui est très très compétent, et
dont les conseils sont excellents à suivre.

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Non, il est dans le cas de figure d'une redirection après un login. Que
la redirection soit ou non la meilleure solution dans ce cas est une
question ouverte - et à laquelle il n'y a probablement pas de réponse
absolue puisque ça dépend aussi de l'architecture applicative. En tout
état de cause, ce n'est AMHA pas une raison (bien au contraire) pour lui
présenter comme vérité d'évangile un avis personnel qui contredit le
standard.

Pour ma part, je n'ais toujours pas compris pourquoi ce serait si mal,
comme je le lit si souvent sur ce newsgroup, d'utiliser un header
location apres un login

L'idée est que ça fait faire un roundtrip de plus entre le client et le
serveur, qui peut être évité par un include. Il est vrai qu'en RTC bas
débit, ça peut faire une différence sensible pour l'internaute. Il est
vrai aussi que ça charge un peu plus le serveur vu qu'il va devoir gérer
deux connections/requêtes au lieu d'une. Il n'est donc pas
nécessairement idiot d'essayer de restreindre l'utilisation des
redirections quand on peut régler le problème autrement tout en
respectant le protocole HTTP.

D'un autre côté, un redirect ne coûte pas si cher qu'il faille
nécessairement essayer de l'éviter à tout prix - et notoirement quand ça
ne respecte plus l'esprit - sinon la lettre - de la RFC.

mes deux centimes...

L'idée est que ça fait faire un roundtrip de plus entre le client et le
serveur, qui peut être évité par un include. Il est vrai qu'en RTC bas
débit, ça peut faire une différence sensible pour l'internaute. Il est
vrai aussi que ça charge un peu plus le serveur vu qu'il va devoir gérer
deux connections/requêtes au lieu d'une. Il n'est donc pas
nécessairement idiot d'essayer de restreindre l'utilisation des
redirections quand on peut régler le problème autrement tout en
respectant le protocole HTTP.

Oui, donc je ne voi vraimnet pas le probleme de l'utiliser apres un
login par exemple : franchement, quand on navigue sur un site, on ne se
logue pas à chaque page, et à partire du moment ou on utilise une
adresse absolue, pas de pb avec la RFC, donc...

Non, il est dans le cas de figure d'une redirection après un login.

Je te dois toutes mes excuses, et à Ben74 aussi, car je n'avais pas vu
ça. Il y a probablement des données de session qui sont passées d'un
script à l'autres, mais comme cette partie du code n'est pas recopiée
dans l'exemple je n'y avais pas pensé.

Ces redirections, sont uniquement ( et strictement ) destinées à
m'affranchir de la limitation imposée par l'hébergeur ( je suis en mutu,
nul n'est parfait... ), quant au délai limite d'exécution d'un script
PHP ( 22 secondes pour l'hébergeur Sivit, ce qui est très peu... ).

[...]

Vous me direz: les include( ) font celà. Oui, mais quand on inclut un
script dans un autre, le script incluant les autres scripts, est soumis
à cette limitation de 22 secondes... Pas faisable donc.

Oui, c'est aussi un cas de figure compréhensible. Cela dit, outre la
possibilité de chercher un autre hébergeur, j'essaierais de négocier
avec lui un délai un peu plus long. Ou bien d'essayer de réduire la
durée des requêtes si c'était possible, par exemple en réorganisant la
base de données -- mais ce n'est pas forcément possible.

(snip)

Ces redirections, sont uniquement ( et strictement ) destinées à
m'affranchir de la limitation imposée par l'hébergeur ( je suis en mutu,
nul n'est parfait... ), quant au délai limite d'exécution d'un script
PHP ( 22 secondes pour l'hébergeur Sivit, ce qui est très peu... ).

[...]

Vous me direz: les include( ) font celà. Oui, mais quand on inclut un
script dans un autre, le script incluant les autres scripts, est soumis
à cette limitation de 22 secondes... Pas faisable donc.

Oui, c'est aussi un cas de figure compréhensible.

Disons que c'est un contournement... qui - pour qui n'en connait pas la
cause - sent un peu le WTF.

Cela dit, outre la
possibilité de chercher un autre hébergeur, j'essaierais de négocier
avec lui un délai un peu plus long.

Le défaut est de 30 secondes.

Ou bien d'essayer de réduire la
durée des requêtes si c'était possible, par exemple en réorganisant la
base de données -- mais ce n'est pas forcément possible.

PAQJS, le temps passé sur des appels bloquants (streams, appels systemes
etc) n'est pas compris dans cette limite. Je n'ai pas vérifié
directement, mais j'aurais tendance à penser qu'il en est de même pour
un accès DB. Si c'est bien le cas, c'est au niveau des autres
traitements (ceux effectués par le/les scripts) qu'il faudrait
intervenir - si c'est possible of course.

Ou bien d'essayer de réduire la
durée des requêtes si c'était possible, par exemple en réorganisant la
base de données -- mais ce n'est pas forcément possible.

PAQJS, le temps passé sur des appels bloquants (streams, appels systemes
etc) n'est pas compris dans cette limite. Je n'ai pas vérifié
directement, mais j'aurais tendance à penser qu'il en est de même pour
un accès DB. Si c'est bien le cas, c'est au niveau des autres
traitements (ceux effectués par le/les scripts) qu'il faudrait
intervenir - si c'est possible of course.

Raison de plus pour regarder si, par hasard, il n'y aurait pas des
traitements (filtres, tris, comparaisons, etc.) qui sont faits en PHP
alors qu'ils seraient réalisés beaucoup plus efficacement par le SGBD.

Bonjour,

Pour ma part, je n'ais toujours pas compris pourquoi ce serait si mal,
comme je le lit si souvent sur ce newsgroup, d'utiliser un header
location apres un login

L'idée est que ça fait faire un roundtrip de plus entre le client et le
serveur, qui peut être évité par un include. Il est vrai qu'en RTC bas
débit, ça peut faire une différence sensible pour l'internaute. Il est
vrai aussi que ça charge un peu plus le serveur vu qu'il va devoir gérer
deux connections/requêtes au lieu d'une.

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]

Il n'est donc pas nécessairement idiot d'essayer de restreindre
l'utilisation des redirections quand on peut régler le problème
autrement tout en respectant le protocole HTTP.

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. Je ne parle pas de surcharge de
méthode, je parle d'un truc du genre:

au lieu de
$objet_destination->méthode($arg1,$arg2);
on ferait *systématiquement*

$central->call('objet_destination', 'méthode', 'arg1','arg2');

avec introspection et sérialisation de l'instance de l'objet
destination qui sera relu en asynchrone par un autre thread chargé de
désérialiser et d'exécuter... C'est en gros le principe de SOAP ou même de
CORBA (encore que) mais c'est pas fait pour tourner en local.

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).

D'un autre côté, un redirect ne coûte pas si cher qu'il faille
nécessairement essayer de l'éviter à tout prix

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,

Pour ma part, je n'ais toujours pas compris pourquoi ce serait si mal,
comme je le lit si souvent sur ce newsgroup, d'utiliser un header
location apres un login

L'idée est que ça fait faire un roundtrip de plus entre le client et le
serveur, qui peut être évité par un include. Il est vrai qu'en RTC bas
débit, ça peut faire une différence sensible pour l'internaute. Il est
vrai aussi que ça charge un peu plus le serveur vu qu'il va devoir gérer
deux connections/requêtes au lieu d'une.

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%...

A moins que tu n'ait des traitements monstrueux pour *chaque* requête
(auquel cas soit il y a quelque chose à revoir de toutes façons, soit le
modèle d'exécution de PHP n'est peut-être pas approprié), la consomation
de ressources n'est quand même pas si monstrueuse que ça. Honnêtement,
il y a aussi d'autres façons de gérer les problèmes de montée en charge.

Accessoirement, dans le cas du traitement d'une requête POST, la faire
suivre d'un redirect est ce qui reste le plus proche des specs HTTP.

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.

Lol !-)

Non, en effet, je ne me soucie pas personnellement de ce genre de
(hum...) "optimisation". Généralement, ce n'est pas à ce niveau là qu'on
gagne le plus... (algorithmes et structures de données anyone ?)

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).

Léger, ton argument, John. Les données confidentielle, soit tu les
stocke en session, soit - si tu dois vraiment les passer dans une
requête (et là, que ce soit en post ou en get ne change pas grand chose)
- tu utilises une connection sécurisée.

Voire la création inutile d'un process de plus pour gérer la requête parce
que pas assez de spare.

Si le serveur n'est pas assez puissant => changer de serveur. Ok, ce
n'est pas une excuse pour programmer comme un goret, mais si par
ailleurs ton serveur est déjà chargé à ce point (et partant du principe
que les redirects sont utilisés à bon escient, dois-je le préciser), ce
n'est pas une ou deux (pseudo) micro-optimisations qui solutionneront
durablement le problème. Mieux vaut garder un code propre et maintenable
et investir dans un serveur sérieux (ou répartir sur quelques serveurs).
Enfin, AMHA et selon mon humble expérience.

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]

Heu... Tu vois souvent du code comme ça, toi ?

En tout état de cause, ce n'est pas le bon emploi des redirections.
Outre le cas évident (la ressource a déménagé), le cas usuel (après un
post qui a réussi), et un ou deux cas périphériques (par exemple gestion
des login, avec utilisation de sessions of course) qui sont parfois peu
ou prou imposés par une archi existente (framework, appli 'pluggable'
etc), je ne vois pas trop de raison d'utiliser un redirect, et
certainement pas celui que tu cites et que je n'ai pour ma part jamais vu.

(snip)

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. Je ne parle pas de surcharge de
méthode, je parle d'un truc du genre:

au lieu de
$objet_destination->méthode($arg1,$arg2);
on ferait *systématiquement*

$central->call('objet_destination', 'méthode', 'arg1','arg2');

avec introspection et sérialisation de l'instance de l'objet
destination qui sera relu en asynchrone par un autre thread chargé de
désérialiser et d'exécuter...

Tu bosses trop avec des développeurs Java, en ce moment. Je ne vois
qu'eux pour imaginer des monstruosités pareilles !-)

(comment ça je trolle ? Mais non je trolle pas !-)

D'un autre côté, un redirect ne coûte pas si cher qu'il faille
nécessairement essayer de l'éviter à tout prix

Comme toujours, l'essentiel est de comprendre les avantages et
inconvénients de chaque méthode.

indeed

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.

Certes, mais c'est vrai pour *beaucoup* d'autres choses. Combien de
bases SQL avec des index sur des champs booléens, par exemple...