Olivier Miakinen a écrit :
(snip)
> Le 24/07/2007 13:33, Jean-Francois Ortolo a écrit :
>> Ces redirections, sont uniquement ( et strictement ) destinées à
>> m'affranchir de la limitation imposée par l'hébergeur ( je suis en mutu,
>> nul n'est parfait... ), quant au délai limite d'exécution d'un script
>> PHP ( 22 secondes pour l'hébergeur Sivit, ce qui est très peu... ).
>>
>> [...]
>>
>> Vous me direz: les include( ) font celà. Oui, mais quand on inclut un
>> script dans un autre, le script incluant les autres scripts, est soumis
>> à cette limitation de 22 secondes... Pas faisable donc.
>
> Oui, c'est aussi un cas de figure compréhensible.

Disons que c'est un contournement... qui - pour qui n'en connait pas la
cause - sent un peu le WTF.

> Cela dit, outre la
> possibilité de chercher un autre hébergeur, j'essaierais de négocier
> avec lui un délai un peu plus long.

Le défaut est de 30 secondes.

> Ou bien d'essayer de réduire la
> durée des requêtes si c'était possible, par exemple en réorganisant la
> base de données -- mais ce n'est pas forcément possible.

PAQJS, le temps passé sur des appels bloquants (streams, appels systemes
etc) n'est pas compris dans cette limite. Je n'ai pas vérifié
directement, mais j'aurais tendance à penser qu'il en est de même pour
un accès DB. Si c'est bien le cas, c'est au niveau des autres
traitements (ceux effectués par le/les scripts) qu'il faudrait
intervenir - si c'est possible of course.

Le 25/07/2007 16:58, Bruno Desthuilliers a écrit :
>
>> Ou bien d'essayer de réduire la
>> durée des requêtes si c'était possible, par exemple en réorganisant la
>> base de données -- mais ce n'est pas forcément possible.
>
> PAQJS, le temps passé sur des appels bloquants (streams, appels systemes
> etc) n'est pas compris dans cette limite. Je n'ai pas vérifié
> directement, mais j'aurais tendance à penser qu'il en est de même pour
> un accès DB. Si c'est bien le cas, c'est au niveau des autres
> traitements (ceux effectués par le/les scripts) qu'il faudrait
> intervenir - si c'est possible of course.

Raison de plus pour regarder si, par hasard, il n'y aurait pas des
traitements (filtres, tris, comparaisons, etc.) qui sont faits en PHP
alors qu'ils seraient réalisés beaucoup plus efficacement par le SGBD.

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

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

Le Mon, 23 Jul 2007 15:17:35 +0000, Olivier Miakinen a écrit:

> Le 23/07/2007 14:51, Ben74 a écrit :

> Mais même dans ce cas là tu devrais commencer par regarder le code HTML
> généré (View/Page source) car il y a sûrement des choses à voir.

Il y aurait peut-être eu des indications dans un autre contexte, mais en
travaillant sur les en-têtes de document, il n'aurait pu avoir d'indices
qu'en examinant les en-têtes de la réponse... Dans le cas présent,
l'indice qu'il aurait du donner est l'adresse affichée par le navigateur
lorsque le serveur répond. Si c'est la même que la page d'origine, la
redirection n'a pas marché, pour x raisons.


> En quelques mots, le header("Location: ...") ne devrais jamais servir à
> rien d'autre qu'à rediriger d'un site vers un autres, et pas entre deux
> pages du même site.

Faux. Ou alors je vous suggère de soumettre vos sources. Rien de tel
n'est mentionné dans la RFC 2616. Et vous connaissez sûrement la
précision utilisée dans ces descriptions: MAY / MAY NOT - MUST / MUST NOT.
Pour tout le reste, il y a le libre arbitre.

Voir RFC2616 14.30 Location

> D'ailleurs il devrait toujours y avoir une URL
> absolue (du genre http://www.example.com/test.html) et jamais une URL
> relative (telle que test.html).

Vrai. Et je parierais même que c'est l'origine du problème.
Nota: Location est à utiliser avec l'une des réponses HTTP 3xx. (ou 201
Created, mais je ne pense pas que ce soit le cas pour notre
demandeur ) )


Julien

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

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