Le Fri, 03 Aug 2007 09:35:19 +0000, John GALLET a écrit:

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

Votre approche ne prend pas du tout en compte la notion des URI. A savoir
donc qu'une ressource spécifique devrait être disponible en un
emplacement spécifique (parfois plusieurs, mais la justification est
rare). L'association *ressource*-*emplacement* permet de gagner
significativement en termes de performances puisqu'elle facilite la mise
en cache des données et on économise du coup tout le traitement de mise
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.


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

Les effets de bords que vous mentionnez sont aussi provoqués par une
mauvaise conception.
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.

Pour cela, il a été inventé des techniques comme celle du jeton de
validation.
Un service quelconque dirige l'utilisateur vers un service
d'authentification. Le service d'authentification délivre un jeton à
l'utilisateur et le redirige vers le service quelconque avec son jeton.
Le service quelconque note la présence du jeton et contacte le service
d'authentification pour savoir si le jeton est valide, et poursuit son
traitement en fonction.
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) et elle
respecte l'idée de "1 endroit pour accéder à 1 service", ce qui permet de
déméler les noeuds dans lesquels on peut se prendre le cerveau lorsqu'il
s'agit de modifier l'application existante ou même simplement de corriger
une erreur.

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,
par le simple manque du concepteur à rendre son service compatible avec
ceux-ci ? A rechercher les gaspillages des autres, on peut aller très
loin sans que les idées reçues ne changent ni même que les concepteurs
revoient leur manière de concevoir...

Cf RFC2616
9.1.1 Safe Methods
15 Security Considerations
15.1.1 Abuse of Server Log Information
15.1.3 Encoding Sensitive Information in URI's


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

Problème de conception, encore. 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.
Ce genre de phénomène n'est donc pas à prendre en compte dans le
développement. Il est plus sage de faire maîtriser les outils et concepts
que de propager la prohibition de ce qui n'est pas interdit.
Si vous ne souhaitez pas le faire, pas de soucis, mais abstenez vous de
la propagande.

Pour la résolution du problème mentionné, cf RFC2616 10.4.4 403 Forbidden


> 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*.
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.",
dans le second, on dit "Oui, je suis habilité à exécuter cette procédure,
un instant s'il vous plaît."


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

Je ne comprends pas votre point de vue, et encore moins quelle est la
situation délirante. Le principe client/serveur sert à alléger une
machinerie lourde. 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.
Le livreur s'est trompé, il faut peut-être prendre conscience qu'il a
fait une erreur. Et qui dit erreur, dit mauvais fonctionnement, ce qui
n'est pas normal en développement d'application.
En revanche, le livreur peut très bien être missionné pour laisser sa
machine à laver dans le camion, aller s'informer auprès de la concierge/
voisin pour savoir où se trouve l'appartement à livrer, s'assurer qu'il
peut livrer, retourner dans son camion et finalement se faire chier à
transporter sa machine de 80Kg sachant où et comment la livrer.

Qui voudrait d'un livreur assez taré pour percer les murs des voisins
quand il se plante de porte ? Et que se passe-t-il s'il se plante
carrément d'étage ? il utilise la machine de 80 Kg comme marteau piqueur
dans la mauvaise buanderie pour l'installer plus facilement dans celle du
voisin d'en dessous ?

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... et on est toujours débordé ! (clin
d'oeil à votre clin d'oeil sur l'utilisation des ressources)


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

C'est ce qui fait toute la différence entre bonne et mauvaise conception.
Une obsession anti-redirections ne vaut pas mieux qu'une obsession pro-
inclusion. L'essentiel étant de mettre en place un système simple, léger
(par rapport à sa fonction), maintenable, qui ne fait rien de plus que ce
qu'il est censé faire et qui fait bien ce qu'il est censé faire.


> JG


Julien