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=abc 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