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"...
Post by Julien PleeVotre approche ne prend pas du tout en compte la notion des URI.
C'est parfaitement exact, et là n'est pas mon propos.
Post by Julien Pleerare). 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...
Post by Julien Pleeen 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...
Post by Julien PleeSi 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.
Post by Julien PleeLes 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.
Post by Julien PleeD'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).
Post by Julien PleeUtilisation 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.
Post by Julien PleeJ'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.
Post by Julien PleeQuand à 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.
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.
Post by Julien PleePost by John GALLET[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.
Post by Julien PleeSi 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.
Post by Julien PleeCe 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.
Post by Julien PleeSi 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.
Post by Julien PleePour la résolution du problème mentionné, cf RFC2616 10.4.4 403 Forbidden
ROTFL ! La page b.php est nécessairement publique !
Post by Julien PleePost by John GALLETMoi 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.
Post by Julien PleeLes 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.
Post by Julien Pleedans 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".
Post by Julien PleeJe ne comprends pas votre point de vue,
Oui ça je l'avais compris.
Post by Julien Pleeet 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.
Post by Julien PleeEt 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.
Post by Julien PleeUn 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