Bonjour,

NB : vous publiez en UTF-8, attention moult serveurs de news ne
propageront pas vos articles. Là aussi, c'est une différence entre "ce
qu'on peut faire" et " qu'il est normal de faire"...

> 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

De manière générale, la mise en cache des données est justement ce que
l'on veut *éviter* quand on fait du web dynamique. Sinon on s'emmerderait
pas à passer des arguments...

> en page. Il est donc faux de prétendre qu'on "bouffe" deux fois
> l'intégralité des ressources.

C'est exact, la seule constante de traitement sans overhead, c'est le
traitement qu'on veut exécuter, appelé en direct ou en redirection. Ceci
étant dit, disséquez l'intégralité dialogue socket, que ce soit en
keep-alive ou non, et repointez les ressources consommées sur tous les
éléments du réseau, du client et du serveur. Mettez vous dans un vrai cas
de site professionnel qui tourne, avec un loadbalanceur sur 7 ou 8
machines (bêtes de course qui coûtent cher à acheter et à héberger, je ne
parle pas de 486 d'occaz), et qui doit générer plusieurs milliers de pages
de contenu par jour, toutes dynamiques à 100%. Vous allez voir, si vos
header Location bouffent pas deux fois les 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.

Quel cache ? A part le SGA ou équivalent avec des requêtes SQL prébindées,
il n'y a aucun cache existant.

> 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
constate en audits quotidiens et qui est dangereuse.

> 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
logs, personne qui aura a posteriori un accès anormal à ces logs ne pourra
la lire, c'est aussi bête que ça. C'est l'un des rares critères de choix
de transmission de GET vs POST (mais là aussi je sens qu'on va encore
repartir pour un tour, ça me fatigue d'avance).

> Utilisation de services spécialisés, pas de transmission de données
> personnelles en clair.

Quand il faut transmettre un login/pass ou numéro de carte bleue, il y a
bien un moment où il transite. Si le crétin de développeur qui le gère
fait un GET, volontaire ou non, ces informations seront stockées en clair
dans un log. Donc qu'on réduise au maximum le nombre de fois où ça
transite, pourquoi pas (ça amène d'autres problèmes, sur la validité du
jeton en question et du session fixation par exemple) mais il faut bien
amorcer la pompe. Et il n'y a pas que ça comme données confidentielles,
loin de là, toute donnée personnelle (coordonnées postales ou
électroniques, etc.) en font partie.

> 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
d'accès dans toutes les applications qui gèrent du contenu, d'une manière
ou d'une autre.

> 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,

Leur quantité est strictement égale à zéro sur une application dynamique,
ou alors justement on a un problème. C'est à tel point qu'on est parfois
obligés de rajouter un compteur bidon ou aléatoire dans les requêtes http
pour ne pas être emmerdés par ces crétins de navigateurs qui ne font pas
la requête de nouveau même quand on leur indique gentiment.

> Cf RFC2616
Je l'ai dit et je le redis: je me tamponne complètement de ce qu'il est
possible de faire, moi dans mon métier, je fais de l'audit de code au
quotidien et ce que je vois en pratique, c'est que 98% des utilisations de
header Location foutent le bordel à un endroit ou à un autre de la chaîne.
C'est tout.

> > [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
l'utilisation d'une *fonctionnalité* au rang de *méthode de développement*
ça va nécessairement créer des problème chez les gens qui n'en ont pas
compris tous les risques.

> 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
l'intellectualisation, c'est beau, mais faut revenir sur terre de temps en
temps. Le niveau moyen de l'intégrateur html-php est de plus en plus
faible. Sécurité ? connais pas. Socket ? Oui j'ai mis mes chaussettes, il
fait froid. Performances ? Boah, on s'en fout, maintenant la puissance...
ah oui quand tu m'en parles, c'est vrai on a des machines qui rament à
mort et des clients pas contents parce qu'ils n'arrivent pas à utiliser le
service, mais c'est pas de ma faute hein ?

Bref, je parle de la *vraie vie*, pas des belles théories.

> 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
la situation pour le faire, faites le, mais n'entraînez pas avec vous la
foultitude de gens qui ne le sont absolument pas.

> 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
machine physique unique en multi-tâche.

> 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
chez le voisin, dans la pièce d'a côté, c'est une exécution immédiate.
header Location, ce n'est pas passer dans la pièce d'a côté, c'est
commencer par redescendre les 10 étages à pied, revenir au rez de chaussée
regarder le plan des locaux, et remonter les 10 étages à pieds pour
revenir à côté. Si vous n'êtes pas capable de comprendre que la belle
théorie des RFCs et tout la bazar implique ça et donc des *gros* problèmes
de performances, c'est votre problème.

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

Autre MALC: quand on me balade de service en service au téléphone, ça me
broute qu'on me passe de poste en poste, mais ça me brouterait encore plus
si on disait systématiquement "voici le numéro qu'il faut rappeler
immédiatement".

> 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
terminal VT-100, d'un deux tiers écrit en Delphi, ou d'un trois tiers sur
support http ? Méfiez vous, la réponse sera pas la même.

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

Et en cas d'erreur dans le header Location ça se passera mieux peut-être ?
Arrêtons les conneries, quand on dit inclusion, on peut (?) avoir
l'intelligence de généraliser à "exécution immédiate de code". Donc
évidemment, si le développeur appelle destroy() à la place d'update() on
va pas aller bien loin, mais que ce code soit appelé directement ou après
ping-pong inutile, ça changera rien au problème.

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

Oui et bien vous allez y retourner à votre con-ception, et le jour où vous
aurez envie de comprendre pourquoi votre bouzin est ras la gueule et ne
répond plus, je vous expliquerai la vraie vie.

Vous avez raison, la belle théorie vous y autorise plus qu'amplement. Dans
la pratique, ça fout le bordel, EOT. Maintenant que vous êtes averti (et
que donc vous valez deux), vous faites ce que vous en voulez, moi je
retourne bosser.

a++;
JG