Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ressources http en POST Re: Aucune recuperation des champs du formulaire

1 view
Skip to first unread message

Nicolas Krebs

unread,
Mar 16, 2009, 4:26:29 PM3/16/09
to
Patrick Mevzek écrivit dans l'article
news:48d7afd9$0$1035$426a...@news.free.fr

> Si la sécurité d'une application est uniquement basée sur le fait que
> c'est un GET plutôt qu'un POST ou le contraire, alors cette application
> n'a aucune réelle mesure de sécurité.
>
> Tous les gens qui croient corriger un problème de sécurité en changeant un
> GET par un POST ne comprennent en général pas grand chose au réel problème
> de sécurité sous-jacent.

Que pouvez vous me dire sur le passage ci-dessous, extrait de l'article de
Stéphane Deschamps, « Spip : notes pour plus tard », section « HTTP, GET et
POST », nota-bene.org, 4 mars 2009,
http://www.nota-bene.org/Spip-notes-pour-plus-tard ?

| Le protocole HTTP fournit deux méthodes principales pour discuter avec
| une page web : GET et POST.
|
| La première demande de recevoir des informations (elle les « gets »), la
| seconde envoie des informations (elle les « poste »).
|
| C'est vital de bien faire la distinction entre ces deux méthodes quand on
| construit un site web, pour éviter par exemple qu'un robot d'indexation
| ne fasse des dommages dans une base de données, idem pour un outil de
| vérification des erreurs dans vos liens, etc.
|
| Vous me direz qu'on est protégé dans une interface d'administration qui
| demande qu'on s'identifie avant de pouvoir l'utiliser ? Certes, mais il
| existe aussi des outils à disposition des simples mortels comme vous et
| moi qui permettent de vérifier que tous les liens de votre site sont bons
| directement dans votre navigateur, par exemple l'extension Link Checker
| pour Firefox, que j'ai fini par désinstaller de peur de la lancer par
| accident !

Annexes :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
http://tools.ietf.org/html/rfc2616#section-9.3
http://tools.ietf.org/html/rfc2616#section-9.5
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#section-7.3
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#section-7.5

Merci d'avance. N'hésitez pas à changer de forum si nécessaire.

Olivier Miakinen

unread,
Mar 16, 2009, 5:25:03 PM3/16/09
to
Le 16/03/2009 21:26, Nicolas Krebs répondit à Patrick Mevzek :

>
>> Si la sécurité d'une application est uniquement basée sur le fait que
>> c'est un GET plutôt qu'un POST ou le contraire, alors cette application
>> n'a aucune réelle mesure de sécurité.
>>
>> Tous les gens qui croient corriger un problème de sécurité en changeant un
>> GET par un POST ne comprennent en général pas grand chose au réel problème
>> de sécurité sous-jacent.

Ça me semble très sensé. Surtout si tu penses aux gens qui trouvent
indispensable de vérifier qu'une requête censée arriver par GET n'arrive
pas par POST, ou le contraire.

> Que pouvez vous me dire sur le passage ci-dessous, extrait de l'article de
> Stéphane Deschamps, « Spip : notes pour plus tard », section « HTTP, GET et
> POST », nota-bene.org, 4 mars 2009,
> http://www.nota-bene.org/Spip-notes-pour-plus-tard ?
>

> | [...]


> |
> | C'est vital de bien faire la distinction entre ces deux méthodes quand on
> | construit un site web, pour éviter par exemple qu'un robot d'indexation
> | ne fasse des dommages dans une base de données, idem pour un outil de
> | vérification des erreurs dans vos liens, etc.

D'une part il ne s'agit pas d'un problème de sécurité : si un robot
d'indexation peut faire des dommages dans une base de données en suivant
un simple lien, c'est qu'il y a un problème de conception à la base.

Par ailleurs, il me semble que la vraie différence ici ne soit pas entre
une requête GET et une requête POST, mais plutôt entre un lien (qui fait
forcément une requête de type GET) et un formulaire (qui *peut* faire
une requête de type POST). Je me trompe peut-être, mais j'ai la
faiblesse de croire qu'un robot d'indexation ou un vérificateur de
liens n'ira pas plus lancer la soumission d'un formulaire s'il est de
type GET que s'il est de type POST.

Patrick Mevzek

unread,
Mar 17, 2009, 9:00:19 PM3/17/09
to
Le Mon, 16 Mar 2009 21:26:29 +0100, Nicolas Krebs a écrit:
>> Si la sécurité d'une application est uniquement basée sur le fait que
>> c'est un GET plutôt qu'un POST ou le contraire, alors cette application
>> n'a aucune réelle mesure de sécurité.
>
> Que pouvez vous me dire sur le passage ci-dessous, extrait de l'article
> de Stéphane Deschamps, « Spip : notes pour plus tard », section « HTTP,
> GET et POST », nota-bene.org, 4 mars 2009,
> http://www.nota-bene.org/Spip-notes-pour-plus-tard ?

(Mieux vaut ne pas trop me lancer sur SPIP :-))

> | Le protocole HTTP fournit deux méthodes principales pour discuter avec
> | une page web : GET et POST.
> |
> | La première demande de recevoir des informations (elle les « gets »),
> la | seconde envoie des informations (elle les « poste »). |

On peut pas dire recevoir et envoyer en français ?

> | C'est vital de bien faire la distinction entre ces deux méthodes quand

Je suis d'accord, les deux méthodes HTTP sont sémantiquement différentes,
non interchangeables et bien décrires dans les RFCs, même s'il y a
parfois des erreurs de mise en oeuvre.

Chacune joue un rôle bien spécifique. Je pense que c'est le fait que les
formulaires puissent être soumis via GET ou POST selon les cas qui a créé
pas mal de confusion...

Cependant, en terme de sécurité, elles ne doivent pas influencer, car
c'est un paramètre qui vient de l'extérieur puisqu'il vient du client,
donc par définition en terme de sécurité, garanti non sûr. Parce que même
s'il y a un lien (qui devrait déclencher un GET) un attaquant peut
s'amuser (que ce soit en javascript ou avec d'autres outils) de tester un
POST (ou un PUT ou un OPTIONS ou tout ce qu'on veut comme méthode HTTP...
d'ailleurs la méthode TRACE est bien intéressante parfois...) sur la même
ressource et inversement, si c'est un formulaire prévu en POST (ou une
horreur comme un javascript qui fait un POST alors qu'un formulaire
aurait largement suffi), un attaquant peut tenter un GET dessus.

Bref, quelque soit le canal de transmission de l'information elle arrive
d'une origine non sûre, donc elle doit être vérifiée. Ce n'est pas parce
qu'elle arrive via le canal GET par opposition au POST ou le contraire
que subitement l'information devient sûre et qu'on peut se passer de
tests. C'est comme les vérifications du contenu d'un formulaire en
javascript avant envoi... cela peut être utile dans certains cas
(traitements lourds côté serveur et filtrage des cas flagrants de
problème, même si de nos jours avec AJAX on peut recommencer à avoir
toutes les vérifications faites côté serveur même avant la soumission
complète effective).

Donc ca ne sert pas à grand chose de s'amuser à tester GET ou POST
d'ailleurs toutes les API haut niveau dans les langages de programmation
permettent l'accès aux données de la même façon que ce soit GET ou POST
(alors que l'encodage des champs d'un formulaire envoyé en GET et le même
en POST n'est pas le même - l'encodage peut être différent)

> on | construit un site web, pour éviter par exemple qu'un robot
> d'indexation | ne fasse des dommages dans une base de données, idem pour
> un outil de | vérification des erreurs dans vos liens, etc. |

Là il s'agit d'un site apparemment qui ne fait pas ce qu'il faut quand
quelqu'un, un humain ou un robot, clique sur un lien ou je ne sais pas...
bref même pas un problème de sécurité, juste de fonctionnalité du site.

> | Vous me direz qu'on est protégé dans une interface d'administration
> qui | demande qu'on s'identifie avant de pouvoir l'utiliser ?

Ah l'authentification... Encore un mot-clef qu'on sort pour dire qu'on
est sécurisé alors que parfois cela n'a pas grand sens.
Combien de fois une authentification se résume au final à une redirection
vers une page... qui est aussi tout à fait accessible directement dès
qu'on connaît (ou devine) son URL ?

> Certes,
> mais il | existe aussi des outils à disposition des simples mortels
> comme vous et | moi qui permettent de vérifier que tous les liens de
> votre site sont bons | directement dans votre navigateur, par exemple
> l'extension Link Checker | pour Firefox, que j'ai fini par désinstaller
> de peur de la lancer par | accident !

Ouh là mon dieu une application a le malheur de cliquer sur tous les
liens (tels que proposés par le serveur web dans la page qu'il sert donc,
sous son contrôle a priori) et c'est supposé créer des problèmes ? Bah il
a un problème ce site, non ?
Et pas un problème de sécurité, un problème tout court.
C'est un site SPIP ? Ah peut-être ca explique alors ... :-)

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>

Pierre Goiffon

unread,
Mar 18, 2009, 5:34:17 AM3/18/09
to
Patrick Mevzek wrote:
>> | Le protocole HTTP fournit deux méthodes principales pour discuter avec
>> | une page web : GET et POST.
>> |
>> | La première demande de recevoir des informations (elle les « gets »),
>> la | seconde envoie des informations (elle les « poste »). |
>
> On peut pas dire recevoir et envoyer en français ?
>
>> | C'est vital de bien faire la distinction entre ces deux méthodes quand
>
> Je suis d'accord, les deux méthodes HTTP sont sémantiquement différentes,
> non interchangeables et bien décrires dans les RFCs, même s'il y a
> parfois des erreurs de mise en oeuvre.

Qu'est-ce qui a conduit initialement à avoir 2 méthodes d'ailleurs ?

Je suppose, l'une qui permet d'envoyer du binaire (input file) et
l'autre qui permet de conserver dans une URL des paramètres ?

A mes débuts j'ai souvent entendu parler de limitation de volumes
lorsque l'on utilise GET, mais je suppose que c'est plutôt lié à ce
fameux "mythe" de la longueur max des URL ? (par convention on utilise
des URL pas trop longues car certains httpd étaient un peu limités dans
le temps)

Je me rappelle que le post contient une information de charset, alors
qu'en get on n'a rien de rien...

> Cependant, en terme de sécurité, elles ne doivent pas influencer, car
> c'est un paramètre qui vient de l'extérieur puisqu'il vient du client,
> donc par définition en terme de sécurité, garanti non sûr.

(...)


> Bref, quelque soit le canal de transmission de l'information elle arrive
> d'une origine non sûre, donc elle doit être vérifiée.

Très bien dis !

>> on | construit un site web, pour éviter par exemple qu'un robot
>> d'indexation | ne fasse des dommages dans une base de données, idem pour
>> un outil de | vérification des erreurs dans vos liens, etc. |
>
> Là il s'agit d'un site apparemment qui ne fait pas ce qu'il faut quand
> quelqu'un, un humain ou un robot, clique sur un lien ou je ne sais pas...
> bref même pas un problème de sécurité, juste de fonctionnalité du site.
>
>> | Vous me direz qu'on est protégé dans une interface d'administration
>> qui | demande qu'on s'identifie avant de pouvoir l'utiliser ?

(...)


>> Certes,
>> mais il | existe aussi des outils à disposition des simples mortels
>> comme vous et | moi qui permettent de vérifier que tous les liens de
>> votre site sont bons | directement dans votre navigateur, par exemple
>> l'extension Link Checker | pour Firefox, que j'ai fini par désinstaller
>> de peur de la lancer par | accident !
>
> Ouh là mon dieu une application a le malheur de cliquer sur tous les
> liens (tels que proposés par le serveur web dans la page qu'il sert donc,
> sous son contrôle a priori) et c'est supposé créer des problèmes ? Bah il
> a un problème ce site, non ?

Je comprend très bien les propos qui sont rapportés !

J'imagine facilement une interface d'administration avec un tableau
d'entrées (liste des articles mettons), pour chaque ligne on a un lien
de suppression, et on n'a pas de demande de confirmation car ce serait
inutilisable sinon. Pour l'utilisateur final, on a des sélections de
plusieurs lignes, menus contextuels etc, mais c'est en JavaScript non
intrusif, et l'interface doit être accessible donc on a bien ces liens
"de base".

L'accès à l'administration nécessite de s'être authentifié, ok. Mais si
on arrive avec son navigateur et que celui-ci va suivre tous les liens
de chaque page, on peut facilement imaginer les catastrophes que cela
peut produire. Comment une application peut-elle gérer cela ?!??

Patrick Mevzek

unread,
Mar 18, 2009, 10:45:55 AM3/18/09
to
Le Wed, 18 Mar 2009 10:34:17 +0100, Pierre Goiffon a écrit:
>> Je suis d'accord, les deux méthodes HTTP sont sémantiquement
>> différentes, non interchangeables et bien décrires dans les RFCs, même
>> s'il y a parfois des erreurs de mise en oeuvre.
>
> Qu'est-ce qui a conduit initialement à avoir 2 méthodes d'ailleurs ?
>
> Je suppose, l'une qui permet d'envoyer du binaire (input file) et
> l'autre qui permet de conserver dans une URL des paramètres ?

Oui.
Le RFC1867 cite spécifiquement le besoin de l'envoi de fichiers comme
motivation pour la création dy type MIME multipart/form-data et l'usage
du POST.



> A mes débuts j'ai souvent entendu parler de limitation de volumes
> lorsque l'on utilise GET, mais je suppose que c'est plutôt lié à ce
> fameux "mythe" de la longueur max des URL ? (par convention on utilise
> des URL pas trop longues car certains httpd étaient un peu limités dans
> le temps)

Ce n'est pas totalement un mythe.
Le RFC2616 est certes "généreux" (§3.2.1) :

The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.


(lire la petite discussion en §10.4.15 qui parle bien justement de l'URI
comme vecteur d'attaque)

Mais Apache par exemple permet de limiter la longueur totale de la ligne
de la requête (et donc l'URL qui est dedans) et le fait par défaut :


LimitRequestLine Directive
Description: Limit the size of the HTTP request line that will be
accepted from the client
Syntax: LimitRequestLine bytes
Default: LimitRequestLine 8190


Il est possible/probable que dans les premières mises en oeuvre les
serveurs web utilisaient un buffer de taille fixe pour l'URI alors que
l'information dans le corps (donc le contenu du POST) pouvait être
allouée dynamiquement en fonction des besoins. Avant que des clients
malfaisants commencent à arriver :-)

> Je me rappelle que le post contient une information de charset, alors
> qu'en get on n'a rien de rien...

En POST, le corps peut être "encodé" de 2 façons différentes, soit
exactement comme le GET (tous les paramètres concaténés par & avec leur
valeur après le =) soit comme un flux MIME avec chaque paramètre/champ
dans un bloc à part et chaque bloc peut avoir des en-têtes MIME et donc
un Content-Type.



> J'imagine facilement une interface d'administration avec un tableau
> d'entrées (liste des articles mettons), pour chaque ligne on a un lien
> de suppression, et on n'a pas de demande de confirmation car ce serait
> inutilisable sinon. Pour l'utilisateur final, on a des sélections de
> plusieurs lignes, menus contextuels etc, mais c'est en JavaScript non
> intrusif, et l'interface doit être accessible donc on a bien ces liens
> "de base".
>
> L'accès à l'administration nécessite de s'être authentifié, ok. Mais si
> on arrive avec son navigateur et que celui-ci va suivre tous les liens
> de chaque page, on peut facilement imaginer les catastrophes que cela
> peut produire. Comment une application peut-elle gérer cela ?!??

Bah là pour le coup effectivement je pense que la différence sémantique
entre GET et POST est très bien illustrée et que dans ce cas précis (une
action qui conduit à un changement significatif du côté du serveur, à
savoir la suppression d'un article). Au pied de la lettre, clairement
cela devrait être un POST donc pas un GET.
Je ne vois pas trop en quoi avoir un formulaire empêcherait les
sélections multiples ou "l'accessibilité". Il doit y avoir moyen de
cumuler toutes ces propriétés, non ?
Et puis l'interface devrait proposer une étape de confirmation
(éventuellement débrayable) ou ne pas réellement détruire de la base mais
mettre dans un état "poubelle" (pour récupération ultérieure possible)
caché ou non.

D'autre part dans cet exemple je ne vois pas bien l'intérêt de lancer une
vérification de tous les liens présents dans la page (j'ose espérer que
l'extension en question dans la navigateur n'est pas programmée pour
automatiquement vérifier tous les liens de toutes les pages vues !). Si
c'est une interface d'administration, a priori non publique, c'est lors
du développement que l'on teste les liens (éventuellement, étant donné
que là la majorité des liens doit être interne), sur un système de test.
C'est bien sûr un peu idyllique mais bon faut se faire une raison aussi...
Application mal concue + éventuellement client mal concu = forcément
problèmes, les deux - ne se compensent pas :-)

[Par contre il y a par défaut dans certains navigateurs la possibilité de
"prefetch" c'est à dire de récupération des pages au bout des liens avant
de cliquer sur les liens pour gagner en performance - téléchargement des
pages probablement "suivantes" pendant qu'on lit la page actuelle - et
donc on aura aussi des soucis si c'est enclenché et que le simple suivi
du lien génère une suppression]

Mais peut-être que, pour revenir à la discussion de départ, on ne parlait
pas vraiment de la sécurité de l'application mais plutôt de la sécurité
de l'utilisateur et de ses données (donc les données dans la base) vis à
vis de l'application et de son comportement. Dans cette acception on
pourrait dire que la "sécurité" est améliorée en utilisant un POST mais
ce n'est en fait qu'une conclusion d'un meilleur choix sémantique et
c'est plus un problème de fonctionnalité pour moi que réellement de
sécurité.

Paul Gaborit

unread,
Mar 18, 2009, 11:04:39 AM3/18/09
to

À (at) Wed, 18 Mar 2009 10:34:17 +0100,
Pierre Goiffon <pgoi...@free.fr.invalid> écrivait (wrote):

> A mes débuts j'ai souvent entendu parler de limitation de volumes
> lorsque l'on utilise GET, mais je suppose que c'est plutôt lié à ce
> fameux "mythe" de la longueur max des URL ? (par convention on utilise
> des URL pas trop longues car certains httpd étaient un peu limités
> dans le temps)

La limite sur la longueur d'un URL existe toujours. Elle est
dépendante à la fois du navigateur et du serveur. À ma connaissance,
la norme HTTP ne fixe rien (ni limite maximum ni même de limite
minimum pour une implémentation).

> Je me rappelle que le post contient une information de charset, alors
> qu'en get on n'a rien de rien...

Pour POST, ça reste à prouver. Dans le format 'multipart/form-data',
la plupart des navigateurs n'envoient aucune information sur le codage
utilisé par les différents champs ! C'est un gros problème qu'on
avait déjà évoqué ici.

Dans une application, on suppose que le données soumises sont codées
en utilisant le codage de la page contenant formulaire correspondant
mais ça ne garantit rien.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Paul Gaborit

unread,
Mar 18, 2009, 11:12:25 AM3/18/09
to

À (at) 18 Mar 2009 14:45:55 GMT,
Patrick Mevzek <pm-N2...@nospam.dotandco.com> écrivait (wrote):

> En POST, le corps peut être "encodé" de 2 façons différentes, soit
> exactement comme le GET (tous les paramètres concaténés par & avec leur
> valeur après le =) soit comme un flux MIME avec chaque paramètre/champ
> dans un bloc à part et chaque bloc peut avoir des en-têtes MIME et donc
> un Content-Type.

Et aucune des ces deux façons de faire ne permet de savoir le ou les
codages utilisés pour les caractères contenus dans les données
transmises. En multipart/form-data, le champ 'Content-Type' de chaque
bloc aurait permis de le faire mais aucun navigateur (à ma
connaissance) ne donne l'information.

Pierre Goiffon

unread,
Mar 18, 2009, 11:31:28 AM3/18/09
to
Paul Gaborit wrote:
> La limite sur la longueur d'un URL existe toujours.

Où ça, puisque pas définie dans "la norme" ? Sur les clients, les
serveurs, ... ?

>> Je me rappelle que le post contient une information de charset, alors
>> qu'en get on n'a rien de rien...
>
> Pour POST, ça reste à prouver. Dans le format 'multipart/form-data',
> la plupart des navigateurs n'envoient aucune information sur le codage
> utilisé par les différents champs ! C'est un gros problème qu'on
> avait déjà évoqué ici.

Je n'avais pas ce souvenir, il faut que je relise des choses...
A commencer par les pages de A.J. Flavell
(http://niwo.mnsys.org/saved/~flavell/charset/form-i18n.html)

Pierre Goiffon

unread,
Mar 18, 2009, 11:47:51 AM3/18/09
to
Patrick Mevzek wrote:
> Le Wed, 18 Mar 2009 10:34:17 +0100, Pierre Goiffon a écrit:
>> A mes débuts j'ai souvent entendu parler de limitation de volumes
>> lorsque l'on utilise GET, mais je suppose que c'est plutôt lié à ce
>> fameux "mythe" de la longueur max des URL ?
>
> Ce n'est pas totalement un mythe.
(...)

> (lire la petite discussion en §10.4.15 qui parle bien justement de l'URI
> comme vecteur d'attaque)

Intéressant, un status de réponse prévu exactement pour que le serveur
refuse une url trop longue...

> Mais Apache par exemple permet de limiter la longueur totale de la ligne
> de la requête (et donc l'URL qui est dedans) et le fait par défaut :

Très intéressant !
J'avais le vague souvenir que le serveurs ne limitaient plus, ou alors
bien au-delà des 250 et quelques caractères dont tout le monde parlait
il y a un peu plus de 10 ans.

>> Je me rappelle que le post contient une information de charset, alors
>> qu'en get on n'a rien de rien...
>
> En POST, le corps peut être "encodé" de 2 façons différentes, soit
> exactement comme le GET (tous les paramètres concaténés par & avec leur
> valeur après le =) soit comme un flux MIME avec chaque paramètre/champ
> dans un bloc à part et chaque bloc peut avoir des en-têtes MIME et donc
> un Content-Type.

Les propos de Paul Gaborit m'interpellent, il y a de quoi creuser, c'est
intéressant !


>> J'imagine facilement une interface d'administration avec un tableau
>> d'entrées (liste des articles mettons), pour chaque ligne on a un lien
>> de suppression, et on n'a pas de demande de confirmation car ce serait
>> inutilisable sinon. Pour l'utilisateur final, on a des sélections de
>> plusieurs lignes, menus contextuels etc, mais c'est en JavaScript non
>> intrusif, et l'interface doit être accessible donc on a bien ces liens
>> "de base".
>>
>> L'accès à l'administration nécessite de s'être authentifié, ok. Mais si
>> on arrive avec son navigateur et que celui-ci va suivre tous les liens
>> de chaque page, on peut facilement imaginer les catastrophes que cela
>> peut produire. Comment une application peut-elle gérer cela ?!??
>
> Bah là pour le coup effectivement je pense que la différence sémantique
> entre GET et POST est très bien illustrée et que dans ce cas précis (une
> action qui conduit à un changement significatif du côté du serveur, à
> savoir la suppression d'un article). Au pied de la lettre, clairement
> cela devrait être un POST donc pas un GET.

Pourquoi serait-ce aussi "au pied de la lettre" une requête en POST ?
L'URL de suppression ne devrait pas avoir à être retenue, certes, donc
on n'a pas l'usage "de base" du get. Mais par contre pas non plus de
fichiers à envoyer. Et construire une URL et rediriger vers celle-ci est
souvent plus simple que de construire un form ou une requête XHR pour
lancer un post...

> Je ne vois pas trop en quoi avoir un formulaire empêcherait les
> sélections multiples ou "l'accessibilité".

Je parlais d'accessibilité pour la présence des liens. La majorité des
interfaces d'admin aujourd'hui ne proposent pas "un lien" pour lancer
une action, mais des menus contextuels, des sélections à la souri,
etc... Bref si ce n'est pas prévu on aurait des actions qui ne sont
accessibles qu'avec du JS (donc ce dont il était question ne provoquerai
pas de dégats).

> Et puis l'interface devrait proposer une étape de confirmation
> (éventuellement débrayable) ou ne pas réellement détruire de la base mais
> mettre dans un état "poubelle" (pour récupération ultérieure possible)
> caché ou non.

Ca serait un choix à adopter en contournement mais ça pose d'autre prb...

> D'autre part dans cet exemple je ne vois pas bien l'intérêt de lancer une
> vérification de tous les liens présents dans la page

Oui pareil, et on en arrive à votre conclusion :

> Application mal concue + éventuellement client mal concu = forcément
> problèmes, les deux - ne se compensent pas :-)

"I couldn't agree more" (non ce n'est rien, j'ai passé un test d'anglais
récemment ;) )

Mais :

> [Par contre il y a par défaut dans certains navigateurs la possibilité de
> "prefetch"

Dans Firefox par exemple... je crois que c'est activé par défaut ? Je
viens de chercher mais j'ai été incapable de retrouver l'option ??

> Mais peut-être que, pour revenir à la discussion de départ, on ne parlait
> pas vraiment de la sécurité de l'application mais plutôt de la sécurité
> de l'utilisateur et de ses données

Oui, le terme était sans doute mal choisit, ou la discussion est partit
en capilotraction incontrôlée.

Paul Gaborit

unread,
Mar 18, 2009, 12:15:52 PM3/18/09
to

À (at) Wed, 18 Mar 2009 16:31:28 +0100,

Pierre Goiffon <pgoi...@free.fr.invalid> écrivait (wrote):
> Paul Gaborit wrote:
>> La limite sur la longueur d'un URL existe toujours.
>
> Où ça, puisque pas définie dans "la norme" ? Sur les clients, les
> serveurs, ... ?

Par "norme", je voulais dire "RFC"... La RFC indique que les clients
comme les serveurs peuvent avoir une limite pour la longueur d'un URL
(d'où le code d'erreur prévu pour le cas où l'URL est trop long côté
serveur). Mais la RFC ne prévoit même pas la taille minimum que
devrait accepter un client. On ne peut donc pas être sûr qu'un URL
fonctionnera sur *tous* les clients... Et surtout on ne sait pas
quelle est la limite inférieure raisonnable (256, 1024, 2048 ?) à
partir de laquelle il faut basculer en POST.

Pierre Goiffon

unread,
Mar 18, 2009, 12:58:51 PM3/18/09
to
Pierre Goiffon wrote:
>>> Je me rappelle que le post contient une information de charset, alors
>>> qu'en get on n'a rien de rien...
>>
>> Pour POST, ça reste à prouver. Dans le format 'multipart/form-data',
>> la plupart des navigateurs n'envoient aucune information sur le codage
>> utilisé par les différents champs ! C'est un gros problème qu'on
>> avait déjà évoqué ici.
>
> (http://niwo.mnsys.org/saved/~flavell/charset/form-i18n.html)

Relu rapidement, la conclusion qui me vient à l'esprit est qu'en
envoyant le formulaire au client en UTF-8, on recevra les valeurs codées
en UTF-8... et on ne devrait pas avoir de cas où un caractère saisi est
en-dehors du jeu de caractère Unicode donc à prioris pas de soucis.

Les passages qui m'ont parus importants :

----8<----8<----
Klaus Weide cites RFC2070 for the client to put a charset attribute
value here, as in this example:

Content-type: application/x-www-form-urlencoded; charset=koi8-r

See RFC2070 section 5.2 for details. However, experience shows that many
poorly-written server-side scripts would be confused by this: a typical
compromise chosen by browser developers is not to to send the charset
attribute if it's identical to the encoding of the page from which the
form is being submitted.
----8<----8<----


----8<----8<----
In practice, browsers normally display the contents of text fields
according to the character encoding (charset) that applies for the HTML
page as a whole; and when it submits the text fields they are
effectively in this same coding. Thus if the server sent out the page
containing the form with a definite charset specification, it could
normally assume that the submitted data can be interpreted in accordance
with the same charset, and this is, at heart, what actually happens.
There are however anomalies of various kinds, some of which have been
seen and understood by the author of this note, some of which have been
seen and not understood, and some of which are only anecdotal.
----8<----8<----


----8<----8<----
multipart/form-data

Ian Graham comments in a usenet posting that browsers don't actually
specify the charset of the MIME parts. Other discussion suggests that
the situation is similar to what we described above for
application/x-www-form-urlencoded: there are so many poorly-coded
server-side scripts out there which can't cope with the presence of this
attribute, that browser implementers are inclined to leave it off if
it's the same as the HTML page from which the form was submitted.
----8<----8<----

Pierre Goiffon

unread,
Mar 18, 2009, 1:00:19 PM3/18/09
to
Paul Gaborit wrote:
>>> La limite sur la longueur d'un URL existe toujours.
>> Où ça, puisque pas définie dans "la norme" ? Sur les clients, les
>> serveurs, ... ?
>
> Par "norme", je voulais dire "RFC"...

Oui, moi également (c'est pourquoi j'avais ajouté des guillemets)

> on ne sait pas
> quelle est la limite inférieure raisonnable (256, 1024, 2048 ?) à
> partir de laquelle il faut basculer en POST.

Ma question était donc d'avoir quelques exemples de logiciels qui
imposaient une limite. Patrick a répondu avec Apache, avec une limite
imposée par défaut (!), j'étais intéressé par en connaître d'autres...

Patrick Mevzek

unread,
Mar 18, 2009, 1:00:53 PM3/18/09
to
Le Wed, 18 Mar 2009 16:47:51 +0100, Pierre Goiffon a écrit:
>>> Je me rappelle que le post contient une information de charset, alors
>>> qu'en get on n'a rien de rien...
>>
>> En POST, le corps peut être "encodé" de 2 façons différentes, soit
>> exactement comme le GET (tous les paramètres concaténés par & avec leur
>> valeur après le =) soit comme un flux MIME avec chaque paramètre/champ
>> dans un bloc à part et chaque bloc peut avoir des en-têtes MIME et donc
>> un Content-Type.
>
> Les propos de Paul Gaborit m'interpellent, il y a de quoi creuser, c'est
> intéressant !

Il y a effectivement tout de prévu dans le "framework" MIME avec le type
application/form-data mais il n'est pas très utilisé, probablement car il
est arrivé trop tardivement (après le démarrage du web/des formulaires)
et trop précocement par rapport aux problèmes de jeux de caractères et de
multilinguisme. Mais bon on peut être un optimiste fini et espéré que le
support des navigateurs change à ce niveau (comme j'ajout du support
NAPTR/SRV, ca serait tellement bien...)



>> Bah là pour le coup effectivement je pense que la différence sémantique
>> entre GET et POST est très bien illustrée et que dans ce cas précis
>> (une action qui conduit à un changement significatif du côté du
>> serveur, à savoir la suppression d'un article). Au pied de la lettre,
>> clairement cela devrait être un POST donc pas un GET.
>
> Pourquoi serait-ce aussi "au pied de la lettre" une requête en POST ?

En fait cela devrait même être une requête avec la méthode DELETE :-)
Mais bon elle est un peu dépréciée... (à part dans un environnement 100%
REST je pense)

Mais bref pour moi (j'ai pas le texte de référence qui va bien en ce sens
là sous la main) un GET ne doit pas avoir d'effets de bord du côté du
serveur (à part la journalisation), bref aucune "écriture".
Et donc si ce n'est pas un GET, il ne reste qu'un POST.
Les liens donnés par notre ami Nicolas en début de fil disent en
particulier pour le POST :
Extending a database through an append operation.

D'accord une suppression ce n'est pas tout à fait un ajout (append),
m'enfin cela me paraît quand même plus proche de cela que d'un GET.
Il y a un "mapping" assez proche entre les méthodes HTTP et les
opérations de base d'un SGBDR :
GET vs SELECT
HEAD vs SELECT ... WHERE 1=0 (pour avoir juste les champs)
DELETE vs DELETE
PUT vs INSERT
POST vs UPDATE

> L'URL de suppression ne devrait pas avoir à être retenue, certes, donc
> on n'a pas l'usage "de base" du get. Mais par contre pas non plus de
> fichiers à envoyer.

Les formulaires en POST c'est certes entre autre pour l'envoi de fichiers
(pas d'autres façons de faire dans ce cas), mais pas seulement.

> Et construire une URL et rediriger vers celle-ci est
> souvent plus simple que de construire un form ou une requête XHR pour
> lancer un post...

Plus simple certes, mais pas avec les mêmes effets :-)
Pour répondre votre exemple, avec sélection multiple, ca serait des cases
à cocher (checkbox) en face de chaque ligne et en bas un bouton
"supprimer les lignes cochées", qui transmet donc un formulaire en POST
et ca résout le problème de l'usage "accidentel" d'un lien "dangereux".

>> Et puis l'interface devrait proposer une étape de confirmation
>> (éventuellement débrayable) ou ne pas réellement détruire de la base
>> mais mettre dans un état "poubelle" (pour récupération ultérieure
>> possible) caché ou non.
>
> Ca serait un choix à adopter en contournement mais ça pose d'autre
> prb...

Certes, mais en toute généralité, compte-tenu des capacités modernes des
ordinateurs, et du fait que les humains se trompent et peuvent supprimer
par erreur et s'en rendre compte 2 secondes après ou parfois 2 mois
après, il me paraît sensé de ne rien supprimer "complétement", mais juste
de faire disparaître de la vue, avec annulation possible pendant un
certain délai. Cela me semble un bon compromis et permet bien des fois de
sortir de la "mouise". Et ce n'est pas tout à fait pareil qu'avec des
sauvegardes qui peuvent aussi aider dans un tel cas mais c'est tout de
même plus simple si cela est prévu directement dans l'application.



>> D'autre part dans cet exemple je ne vois pas bien l'intérêt de lancer
>> une vérification de tous les liens présents dans la page
>
> Oui pareil, et on en arrive à votre conclusion :
>
>> Application mal concue + éventuellement client mal concu = forcément
>> problèmes, les deux - ne se compensent pas :-)
>
> "I couldn't agree more" (non ce n'est rien, j'ai passé un test d'anglais
> récemment ;) )

I hope it was successful !

>> [Par contre il y a par défaut dans certains navigateurs la possibilité
>> de "prefetch"
>
> Dans Firefox par exemple... je crois que c'est activé par défaut ? Je
> viens de chercher mais j'ai été incapable de retrouver l'option ??

Cela semble ne pas être dans les préférences de ce que je vois mais un
about:config me révèle bien :
network.prefetch-next;true

Je n'ai pas vérifié concrétement sur le réseau.

C'est aussi ce qu'indique tous les articles parlant de cela... avec une
recommandation générale de désactivation. Probablement quelque chose qui
devrait être géré plus finement dans une extension (si elle n'existe pas
déjà)

Il est probable qu'il y ait certaines limites pour désactiver
automatiquement cela dans les zones HTTPS, ou après authentification.

D'ailleurs si on lit le document qui va bien tout s'éclaire (et je me
suis alarmé pour rien) :
https://developer.mozilla.org/En/Link_prefetching_FAQ

En résumé :
- il faut que le serveur précise quelles pages sont à charger
(ce n'est pas la navigateur qui décide)
- les liens dans des <a> ne sont PAS suivis
(cela semble éventuellement prévu pour le futur, mais les liens devront
avoir rel="next" ou rel="prefetch" donc pas par défaut)
- les liens en https:// ne sont jamais gérés ainsi, ainsi que les
adresses avec des paramètres (query-string)

J'apprend au passage que la prochaine version majeure de Firefox (la 3.5)
aura du "DNS prefetching" et cela me fait penser à d'éventuelles futures
attaques par ce biais.



>> Mais peut-être que, pour revenir à la discussion de départ, on ne
>> parlait pas vraiment de la sécurité de l'application mais plutôt de la
>> sécurité de l'utilisateur et de ses données
>
> Oui, le terme était sans doute mal choisit, ou la discussion est partit
> en capilotraction incontrôlée.

On nous a peut-être tendu un piège à dessein :-) !

Patrick Mevzek

unread,
Mar 18, 2009, 1:09:49 PM3/18/09
to
Le Wed, 18 Mar 2009 17:15:52 +0100, Paul Gaborit a écrit:
> On ne peut donc pas être sûr qu'un URL fonctionnera
> sur *tous* les clients... Et surtout on ne sait pas quelle est la limite
> inférieure raisonnable (256, 1024, 2048 ?) à partir de laquelle il faut
> basculer en POST.

J'ai tendance à donner à mes étudiants un choix conservateur :

- prendre en gros 1000 comme taille limite (j'ose espérer qu'aucun
serveur digne de ce nom ne coince en deca)

- réfléchir au contenu du formulaire : s'il y a le moindre champ en
"texte libre" c'est à dire où l'utilisateur peut, dans le fonctionnement
nominal, mettre un contenu non nécessairement borné (ex: un cv), alors on
passe direct en POST. Par contre si on n'a que des champs de type cases à
cocher/boutons alors on peut rester en GET tant qu'on n'en a pas
plusieurs dizaines (indépendamment des autres considérations sémantiques
sur GET/POST)
Dans les autres cas un client +/- malfaisant pourrait abuser et essayer
d'envoyer davantage mais alors justement la limite imposée par le serveur
(cf mes exemples Apache) est une bonne chose car cela bloquera l'attaque.


Ainsi on devrait éviter normalement de se poser longuement des questions
quand "il manque des champs" du côté serveur (ce qui peut aussi indiquer
que le formulaire est "mal" fait en général remplir un truc avec des
dizaines de choix ca devient vite rébarbatif, je suis sûr qu'on peut même
trouver des études d'accessibilité sur ce genre de choses, du côté de
Nielsen et compagnie).

Mais ce ne sont bien sûr que quelques grandes lignes, pas de règle
stricte...

Paul Gaborit

unread,
Mar 18, 2009, 1:07:56 PM3/18/09
to

À (at) Wed, 18 Mar 2009 18:00:19 +0100,

Pierre Goiffon <pgoi...@free.fr.invalid> écrivait (wrote):
> Paul Gaborit wrote:
>> on ne sait pas quelle est la limite inférieure raisonnable (256,
>> 1024, 2048 ?) à partir de laquelle il faut basculer en POST.
>
> Ma question était donc d'avoir quelques exemples de logiciels qui
> imposaient une limite. Patrick a répondu avec Apache, avec une limite
> imposée par défaut (!), j'étais intéressé par en connaître d'autres...

L'exemple Apache est côté serveur et la RFC prévoit explicitement un
code d'erreur pour gérer ce cas. Mais côté client, je n'ai jamais
cherché à connaître ces limites (elles existent, c'est sûr).

Paul Gaborit

unread,
Mar 18, 2009, 1:06:42 PM3/18/09
to

À (at) Wed, 18 Mar 2009 17:58:51 +0100,

Pierre Goiffon <pgoi...@free.fr.invalid> écrivait (wrote):
> Pierre Goiffon wrote:
>>>> Je me rappelle que le post contient une information de charset, alors
>>>> qu'en get on n'a rien de rien...
>>>
>>> Pour POST, ça reste à prouver. Dans le format 'multipart/form-data',
>>> la plupart des navigateurs n'envoient aucune information sur le codage
>>> utilisé par les différents champs ! C'est un gros problème qu'on
>>> avait déjà évoqué ici.
>>
>> (http://niwo.mnsys.org/saved/~flavell/charset/form-i18n.html)
>
> Relu rapidement, la conclusion qui me vient à l'esprit est qu'en
> envoyant le formulaire au client en UTF-8, on recevra les valeurs
> codées en UTF-8... et on ne devrait pas avoir de cas où un caractère
> saisi est en-dehors du jeu de caractère Unicode donc à prioris pas de
> soucis.

Attention, Unicode c'est le jeu de caractère, ce n'est pas son codage.

Mais votre conclusion n'est qu'un supposition. On suppose que la
requête qu'on reçoit a été créée depuis notre formulaire.

Mais prenez l'exemple de Google : je peux très bien inclure un petit
formulaire d'accès à Google dans mes propres pages. Comment fait
Google pour savoir l'encodage utilisé ?

Pierre Goiffon

unread,
Mar 20, 2009, 1:41:28 PM3/20/09
to
Patrick Mevzek wrote:
> (comme j'ajout du support
> NAPTR/SRV, ca serait tellement bien...)

Je ne connaissais pas, Wikipedia m'a donné quelques renseignements
(http://fr.wikipedia.org/wiki/Domain_Name_System#NAPTR_record)
Les entrées SRV commencent-elles vraiment à remplacer les MX ??

>>> Bah là pour le coup effectivement je pense que la différence sémantique
>>> entre GET et POST est très bien illustrée et que dans ce cas précis
>>> (une action qui conduit à un changement significatif du côté du
>>> serveur, à savoir la suppression d'un article). Au pied de la lettre,
>>> clairement cela devrait être un POST donc pas un GET.

>> Pourquoi serait-ce aussi "au pied de la lettre" une requête en POST ?

> Mais bref pour moi (j'ai pas le texte de référence qui va bien en ce sens

> là sous la main) un GET ne doit pas avoir d'effets de bord du côté du
> serveur (à part la journalisation), bref aucune "écriture".
> Et donc si ce n'est pas un GET, il ne reste qu'un POST.

Compris.

>> "I couldn't agree more" (non ce n'est rien, j'ai passé un test d'anglais
>> récemment ;) )
>
> I hope it was successful !

Note moyenne (découvert au passage qu'il y a un nombre impressionnant
d'échelles de notation - le niveau 5 ALTE semble difficilement
atteignable d'ailleurs ?

>>> [Par contre il y a par défaut dans certains navigateurs la possibilité
>>> de "prefetch"

>> Dans Firefox par exemple... je crois que c'est activé par défaut ?

> https://developer.mozilla.org/En/Link_prefetching_FAQ

Bravo, et merci de ces recherches, très intéressant !

>>> Mais peut-être que, pour revenir à la discussion de départ, on ne
>>> parlait pas vraiment de la sécurité de l'application mais plutôt de la
>>> sécurité de l'utilisateur et de ses données
>> Oui, le terme était sans doute mal choisit, ou la discussion est partit
>> en capilotraction incontrôlée.
>
> On nous a peut-être tendu un piège à dessein :-) !

:)

Pierre Goiffon

unread,
Mar 20, 2009, 1:46:48 PM3/20/09
to
Paul Gaborit wrote:
>>> (http://niwo.mnsys.org/saved/~flavell/charset/form-i18n.html)
>> Relu rapidement, la conclusion qui me vient à l'esprit est qu'en
>> envoyant le formulaire au client en UTF-8, on recevra les valeurs
>> codées en UTF-8... et on ne devrait pas avoir de cas où un caractère
>> saisi est en-dehors du jeu de caractère Unicode donc à prioris pas de
>> soucis.
>
> Attention, Unicode c'est le jeu de caractère, ce n'est pas son codage.

Oui, UTF-8 est l'un des codages possibles pour le jeu Unicode.

> Mais votre conclusion n'est qu'un supposition. On suppose que la
> requête qu'on reçoit a été créée depuis notre formulaire.
>
> Mais prenez l'exemple de Google : je peux très bien inclure un petit
> formulaire d'accès à Google dans mes propres pages. Comment fait
> Google pour savoir l'encodage utilisé ?

C'est un besoin un peu éloigné de l'usage courant...
La page de Alan J Flavell donne quelques exemples de techniques à
utiliser... On peut en imaginer d'autres...

Patrick Mevzek

unread,
Mar 20, 2009, 9:42:24 PM3/20/09
to
Le Fri, 20 Mar 2009 18:41:28 +0100, Pierre Goiffon a écrit:
>> (comme j'ajout du support
>> NAPTR/SRV, ca serait tellement bien...)
>
> Je ne connaissais pas, Wikipedia m'a donné quelques renseignements
> (http://fr.wikipedia.org/wiki/Domain_Name_System#NAPTR_record)

En gros ca permettrait (enfin ca permet mais personne s'en sert)
1) de plus avoir besoin de numéros de ports fixes pour les services, ie
le possesseur de example.com peut explicitement dire dans sa zone sur
quel port de quelle machine se situe le service "http over tcp"
2) de faire du load balancing et de tolérance au panne (un peu comme le
MX mais plus flexible et surtout applicable à tous les protocoles)
3) d'avoir des expressions régulières/rationnelles dans le DNS pour faire
des "réécritures"

> Les entrées SRV commencent-elles vraiment à remplacer les MX ??

NAPTR/SRV sont surtout utilisés pour les "nouveaux" services, il n'y a
pas trop de rétroportage vers les anciennes technologies (ce qui est à la
fois bien et pas bien, mais bon par exemple le MX n'a pas été la première
solution, il y avait même avant - de mémoire - des enregistrements de
type MAILA et MAILB pour faire ce qu'on fait avec les MX de nos jours).

Mais les nouveaux services utilisent cela quand c'est pertinent.
ENUM par exemple, mais surtout sur les aspects "réécriture" et "routage"
des URI. C'est par exemple le coeur du fonctionnement du nouveau
gTLD .TEL qui est justement en train de démarrer.
Le protocol IRIS (en gros un successeur du whois) utilise aussi NAPTR
dans l'usage canonique du client qui cherche une machine donnant un
service donné dans un certaine autorité sans avoir à coder en dur des
numéros de port, pour prendre un exemple parmi les domaines auxquels je
m'intéresse.
Mais il y a probablement d'autres exemples. C'est juste que bon ce n'est
pas comme si du jour au lendemain Firefox supportait ca (il me semble
avoir lu une soumission de bug à ce sujet il y a un moment déjà mais le
sentiment général que j'avais retenu est qu'on répondait que c'était trop
compliqué et posait des problèmes - mais je n'ai plus du tout les détails
en tête).
D'ailleurs ca me fait penser qu'ils auraient dû "obliger" cela lors du
passage à IPv6 car cela aurait éviter de mettre des numéros de port et
donc des syntaxes que je trouve affreuses du style
http://[2001:db8::1]:80/

Nicolas Krebs

unread,
Mar 21, 2009, 9:01:45 AM3/21/09
to
Patrick Mevzek écrivit dans l'article
news:49c047a3$0$24706$426a...@news.free.fr

> Mieux vaut ne pas trop me lancer sur SPIP :-)

Quelle est votre appréciation de la mutualisation (1) de SPIP 2.0, et
quelles améliorations suggérieriez vous ?
http://www.spip.net/fr_article3514.html
http://www.spip-contrib.net/Mutualisation
http://www.spip-contrib.net/Plugin-Mutualisation

1 : équivalent du « multiblog » de Dotclear 2
( http://fr.dotclear.org/documentation/2.0/admin/multiblog ) et et
Wordpress, autres logiciels serveurs web pour lesquels vous pouvez aussi
rpondre aux questions ci-dessus.

Patrick Mevzek

unread,
Mar 21, 2009, 5:04:16 PM3/21/09
to Nicolas Krebs
Le Sat, 21 Mar 2009 14:01:45 +0100, Nicolas Krebs a écrit:

( Je garde juste .auteurs le plus approprié selon moi)

>> Mieux vaut ne pas trop me lancer sur SPIP :-)
>
> Quelle est votre appréciation de la mutualisation (1) de SPIP 2.0, et

Je dirai qu'il était grand temps (mais trop tard pour moi), dans le sens
où, pour moi, n'importe quel CMS qui
- n'est pas 100% Unicode/UTF-8
- n'est pas capable d'utiliser d'autres SGBDR que MySQL
- n'est pas capable de gérer plusieurs sites avec une même installation
(ce qui est indispensable dès qu'on gère de nombreux sites et qu'on veut
être sérieux question sécurité, point non négligeable pour des logiciels
comme SPIP ou d'autres similaires)
n'est pas vraiment digne de ce nom et a de sérieux inconvénients pas
rapport à ses concurrents.

Donc on peut louer le fait que le point 3 ait avancé (je crois que le 1
aussi mais + ou -, et j'ai des doutes sur le 2), mais regretter que ce
soit si tard dans le projet.

Alors après, oui, c'est un logiciel libre donc personne ne devrait se
plaindre s'il manque X ou Y dedans, mais fournir des patchs et être
constructif. Donc mon avis n'a pas plus d'importance que l'avis de
n'importe qui d'autre, et il n'y a probablement pas nécessite à en
discuter réellement (j'attends le dring du micro-ondes là...)

Mais bref, comme je dis à mes étudiants, beaucoup de projets démarrent en
se disant : le multilinguisme c'est bien mais on verra plus tard (et hop
on fait tout en US-ASCII même sans le savoir), et l'abstraction aux bases
de données c'est bien mais trop compliqué on verra plus tard utilisons
MySQL (ce qui ne serait presque pas trop grave si MySQL initialement ne
"bastardisait" pas tant le SQL ce qui faisait/fait qu'indépendamment du
support on en viens à voir des syntaxes SQL foireuses).
Résultat : il faut au final ajouter tout cela en cours de route, au
dernier moment, quand c'est difficile à faire proprement puisqu'on doit
assurer en général la compatibilité ascendante. Et même si on arrive à
une solution parfaite (ce qui est rare) cela fait énormément plus de
travail que si cela avait été fait dès le début.

Donc c'est un peu la solution que je retiens, car je vois ce phénomène
sur pléthore de logiciels libres.

> quelles améliorations suggérieriez vous ?

Rien de précis, je ne suis pas utilisateur direct. Et pas préconisateur à
titre personnel (j'ai vu trop de mauvais exemples d'usage - ce qu'on peut
reprocher autant à l'outil qu'à l'utilisateur (le webmaster) qui en fait
mauvais usage , on peut faire un mauvais usage même d'un excellent
outil), mon chouchou c'est Drupal (et Serendipity pour les blogs).

Il y a un débat qui revient en permanence sur .php au sujet de templates
ou pas templates, certains prétendant qu'à partir du moment où on avait
un langage de programmation en gros dans le template, autant apprendre
PHP, dont le créateur lui-même estime que c'est un langage de template et
qu'il n'y a donc pas besoin de bibliothèque de template à part entière
(comme Smarty)
Eh bien, pour moi, si les templates sont utiles, un CMS qui impose autant
une nouvelle syntaxe que le fait SPIP me fait *personnellement* estimer
que ce n'est pas la bonne voie qui est suivie, parce que là l'argument
"quitte à apprendre un langage de programmation, autant apprendre le plus
bas niveau, c'est à dire PHP dans le contexte en question" me paraît 100%
recevable.

Après si on devait vraiment discuter, je pourrais aussi ressortir les
premiers avis qu'on pouvait lire sur le support de XHTML, le fork SPIP-
Agora, la finalisation très tardive d'une arborescence logique et saine
(en termes de droits d'accès en tout cas etc.), le passage .php3 à .php,
les URLs vraiment pas belles par défaut (sauf si les défauts ont changé
récemment), etc.

Mais on peut estimer que SPIP répond à un besoin et a une niche
(francophone plutôt et sites web style journaux, cela me paraît prévu
pour cela et pas vraiment pour autre chose), et donc c'est l'essentiel,
après peu importe s'il n'est pas techniquement 100% pur à mes yeux ou à
ceux de n'importe qui d'autre, tant qu'il comble certains dans leurs
usages spécifiques.

Nicolas Krebs

unread,
Mar 22, 2009, 9:15:21 AM3/22/09
to
Patrick Mevzek écrivit dans l'article
news:49c55650$0$6032$426a...@news.free.fr

Merci pour votre réponse. Concernant

> pour moi, n'importe quel CMS qui
> - n'est pas 100% Unicode/UTF-8
> - n'est pas capable d'utiliser d'autres SGBDR que MySQL
> - n'est pas capable de gérer plusieurs sites avec une même installation
> (ce qui est indispensable dès qu'on gère de nombreux sites et qu'on veut
> être sérieux question sécurité, point non négligeable pour des logiciels
> comme SPIP ou d'autres similaires)
> n'est pas vraiment digne de ce nom et a de sérieux inconvénients pas
> rapport à ses concurrents.
>
> Donc on peut louer le fait que le point 3 ait avancé (je crois que le 1
> aussi mais + ou -, et j'ai des doutes sur le 2), mais regretter que ce
> soit si tard dans le projet.

SPIP est 100% Unicode depuis plusieurs versions.
Pour le point 2, c'est fait depuis la version 2.0
( http://www.spip.net/fr_article3683.html
http://www.spip.net/fr_article3784.html )

Pierre Goiffon

unread,
Mar 23, 2009, 5:15:07 AM3/23/09
to
Patrick Mevzek wrote:
> Le Fri, 20 Mar 2009 18:41:28 +0100, Pierre Goiffon a écrit:
>>> (comme j'ajout du support
>>> NAPTR/SRV, ca serait tellement bien...)

>> Je ne connaissais pas

> En gros ca permettrait
(...)

Merci des explications !

Pierre Goiffon

unread,
Mar 23, 2009, 5:24:21 AM3/23/09
to
Patrick Mevzek wrote:
> (j'attends le dring du micro-ondes là...)

He bien, soit vous écrivez très vite soit le micro-onde est un peu
longuet ;)

> Mais bref, comme je dis à mes étudiants, beaucoup de projets démarrent en
> se disant : le multilinguisme c'est bien mais on verra plus tard (et hop
> on fait tout en US-ASCII même sans le savoir), et l'abstraction aux bases
> de données c'est bien mais trop compliqué on verra plus tard utilisons
> MySQL (ce qui ne serait presque pas trop grave si MySQL initialement ne
> "bastardisait" pas tant le SQL ce qui faisait/fait qu'indépendamment du
> support on en viens à voir des syntaxes SQL foireuses).
> Résultat : il faut au final ajouter tout cela en cours de route, au
> dernier moment, quand c'est difficile à faire proprement puisqu'on doit
> assurer en général la compatibilité ascendante. Et même si on arrive à
> une solution parfaite (ce qui est rare) cela fait énormément plus de
> travail que si cela avait été fait dès le début.

Certes... Mais c'est tout à fait les problématiques auxquelles on se
retrouve confronté lorsque l'on gère un produit !

Je ne connais pas parfaitement Spip, mais je crois me rappeler qu'il a
démarré de manière fort modeste, et à une époque où les CMS existants
étaient payants (très cher), pas open source ?
A moins que je me fasse une idée, je comprend donc aisément l'historique
que vous citez...

> Il y a un débat qui revient en permanence sur .php au sujet de templates
> ou pas templates, certains prétendant qu'à partir du moment où on avait
> un langage de programmation en gros dans le template, autant apprendre
> PHP, dont le créateur lui-même estime que c'est un langage de template et
> qu'il n'y a donc pas besoin de bibliothèque de template à part entière
> (comme Smarty)

Smarty est aussi un moteur de cache !

De mon expérience (il y a 5 ans, produit de ecommerce utilisant Smarty,
et depuis plusieurs années templates Wordpress) l'utilisation de la
syntaxe Smarty est vraiment agréable car elle est simple et très
concise. Si je compare aux templates Wordpress, j'ai apprécié cette 2eme
syntaxe pour des choses simples (titres en majuscules par exemple).

Par contre, dans ce débat il faut bien dire qu'il est quand même je
crois très rare, si le cms est bien fait, de devoir ajouter du
traitement dans les fichiers du template lui-même !

Olivier Masson

unread,
Mar 23, 2009, 6:30:21 AM3/23/09
to
Patrick Mevzek a écrit :

> En gros ca permettrait (enfin ca permet mais personne s'en sert)
> 1) de plus avoir besoin de numéros de ports fixes pour les services, ie
> le possesseur de example.com peut explicitement dire dans sa zone sur
> quel port de quelle machine se situe le service "http over tcp"
> 2) de faire du load balancing et de tolérance au panne (un peu comme le
> MX mais plus flexible et surtout applicable à tous les protocoles)
> 3) d'avoir des expressions régulières/rationnelles dans le DNS pour faire
> des "réécritures"
>

Super !
Si j'apprends à mettre cela en place et que je le fais pour mes DNS,
cela ne fonctionnera pas ?

Patrick Mevzek

unread,
Mar 23, 2009, 10:29:30 AM3/23/09
to
Le Mon, 23 Mar 2009 11:30:21 +0100, Olivier Masson a écrit:
> Si j'apprends à mettre cela en place et que je le fais pour mes DNS,
> cela ne fonctionnera pas ?

Si on parle uniquement de HTTP (pour rester on topic), cela marcherait...
si des clients s'en servaient, et malheureusement je pense qu'aucun
navigateur ne tient compte des enregistrements NAPTR/SRV. C'est en partie
le même problème qu'IPv6 ou d'autres technologies : pas de services avec
car pas (trop) de clients avec, et pas de clients avec car pas trop de
services.
Il faut attendre des motivations économiques et pas techniques pour que
cela bouge.

Patrick Mevzek

unread,
Mar 23, 2009, 10:34:54 AM3/23/09
to
Le Mon, 23 Mar 2009 10:24:21 +0100, Pierre Goiffon a écrit:
>> Mais bref, comme je dis à mes étudiants, beaucoup de projets démarrent
>> en se disant : le multilinguisme c'est bien mais on verra plus tard (et
>> hop on fait tout en US-ASCII même sans le savoir), et l'abstraction aux
>> bases de données c'est bien mais trop compliqué on verra plus tard
>> utilisons MySQL (ce qui ne serait presque pas trop grave si MySQL
>> initialement ne "bastardisait" pas tant le SQL ce qui faisait/fait
>> qu'indépendamment du support on en viens à voir des syntaxes SQL
>> foireuses). Résultat : il faut au final ajouter tout cela en cours de
>> route, au dernier moment, quand c'est difficile à faire proprement
>> puisqu'on doit assurer en général la compatibilité ascendante. Et même
>> si on arrive à une solution parfaite (ce qui est rare) cela fait
>> énormément plus de travail que si cela avait été fait dès le début.
>
> Certes... Mais c'est tout à fait les problématiques auxquelles on se
> retrouve confronté lorsque l'on gère un produit !

Je suis tout à fait d'accord. Mais comme c'est "connu" (ie problèmes
typiques auxquels on est confronté), on peut en tenir compte dès le début.



> Je ne connais pas parfaitement Spip, mais je crois me rappeler qu'il a
> démarré de manière fort modeste, et à une époque où les CMS existants
> étaient payants (très cher), pas open source ? A moins que je me fasse
> une idée, je comprend donc aisément l'historique que vous citez...

C'était sûrement le cas, mais cela ne "justifie" pas plus dans un sens
que dans l'autre, c'est juste "malheureux"/dommage.

> De mon expérience (il y a 5 ans, produit de ecommerce utilisant Smarty,
> et depuis plusieurs années templates Wordpress) l'utilisation de la
> syntaxe Smarty est vraiment agréable car elle est simple et très
> concise. Si je compare aux templates Wordpress, j'ai apprécié cette 2eme
> syntaxe pour des choses simples (titres en majuscules par exemple).

(pour que ce soit clair: 1) j'adore Smarty 2) je n'aime pas trop PHP 3)
je pense que les templates - quelque que soit le langage, PHP y compris -
sont un outil très utile et pas à jeter a priori)



> Par contre, dans ce débat il faut bien dire qu'il est quand même je
> crois très rare, si le cms est bien fait, de devoir ajouter du
> traitement dans les fichiers du template lui-même !

Cela dépend du site... et il y a toute une syntaxe SPIP avec des
<BOUCLE_articles> , #TITRE , #INCLURE etc...
Exemple: http://www.spip.net/fr_article898.html

C'est sur ce point que je disais dans mon précédent message que je
trouvais personnellement que SPIP "lost its way" comme CMS en définissant
en gros un nouveau langage...

Pierre Goiffon

unread,
Mar 24, 2009, 6:42:23 AM3/24/09
to
Patrick Mevzek wrote:
>>> Mais bref, comme je dis à mes étudiants, beaucoup de projets démarrent
>>> en se disant : le multilinguisme c'est bien mais on verra plus tard (et
>>> hop on fait tout en US-ASCII même sans le savoir), et l'abstraction aux
>>> bases de données c'est bien mais trop compliqué on verra plus tard

>> Certes... Mais c'est tout à fait les problématiques auxquelles on se


>> retrouve confronté lorsque l'on gère un produit !
>
> Je suis tout à fait d'accord. Mais comme c'est "connu" (ie problèmes
> typiques auxquels on est confronté), on peut en tenir compte dès le début.

C'est plutôt une question d'objectifs à se fixer, et on ne peut pas
toujours avoir les bonnes réponses : les demandes utilisateurs comme la
concurrence évoluent sans cesse ! Ce n'est pas une tâche facile que de
poser les bases d'un produit sur un usage récent, qui sera amené à se
développer sans que l'on puisse vraiment imaginer dans quelles directions.

> il y a toute une syntaxe SPIP avec des
> <BOUCLE_articles> , #TITRE , #INCLURE etc...
> Exemple: http://www.spip.net/fr_article898.html

Merci du lien, j'avais beaucoup entendu parler de cette syntaxe, avec
cette doc c'est très parlant !

0 new messages