John GALLET a écrit :
> 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=abc 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...