Le fait d'envoyer du code au client repond a une problematique bien precise que tous les protocoles du monde ne peuvent resoudre.
Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Le probleme, c'est de faire tourner du code cote client, ca te defrise peut etre, mais eviter un aller retour au serveur quand un formulaire est invalide ou qu'on veut juste rafraichir un div, tu vas avoir du mal a le resoudre au niveau protocolaire.
Tu parles avec une vision très "web centrée". Ton formulaire il sert à quoi, finalement ? À publier un commentaire sur LinuxFR ? Avec NNTP (par exemple) le serveur n'a pas à se soucier de la forme des données, c'est le client qui respecte le format et va, par exemple, dire "cette adresse mail est bizarre, j'envoie quand même ?" ou "Attention, message vide !". Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile. Quoi que, y'a pas mal de poutrages de services Web qui se font en partie à cause de ça (path disclosure, injection SQL). Des failles récurrentes, inimaginables sur d'autres protocoles.
Le concept de ressource etant volontairement le plus vague possible, car ca peut etre n'importe quoi. Un put sur un salon de discussion, un delete sur un email ou autre.
On a réinventé TCP/IP, super :)
Et par dessus ce HTTP, ben on code des applis, qui pourraient très bien être codées en utilisant directement TCP/IP et en tournant nativement chez l'utilisateur. Moins de ressources réseau et CPU gâchées. Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Que status.net fasse visiblement portnawak (ou plutot que ce qu'il fait t'echappe)
Ouais, j'avoue que ce gloubi-boulga m'échappe. Faut se lever de bonne heure pour comprendre et débugger une "application Web", c'est à dire, d'un point de vue système, un serveur Web qui sert des pages, lesquelles sont en fait des scripts qui tapent dans une base de données en s'authentifiant pour ensuite renvoyer du contenu HTML,et du javascript qui fait des trucs côté client afin que le client vienne faire d'autres trucs sur le serveur, ou des cookies.. Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Mais qu'est ce que ca a voir avec http ca? Serieusement? Ssl gueule en cas de certificat auto signe, oui c'est normal, vu que le but du jeu c'est d'avoir une authentificaton de la source par un tiers de confiance. Si le tiers est inconnu, il n'est pas de confiance et donc ca gueule, c'est quoi le pb au juste?
Ça a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois. Ce qui est très différent de notifier l'utilisateur. Un débutant, je peux le guider au téléphone et lui confirmer (par exemple) le certificat auto-signé d'un serveur Jabber. Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber. Pire que ça : il n'aura même pas la possibilité d'accepter ce certificat uniquement pour un site précis, soit il fait confiance totale au propriétaire du certificat (y compris pour sa banque, ses mails..), soit il visite le site en version sans SSL. Super. Pendant ce temps, Gajim (c'est pas un projet aussi gros que Firefox hein) affiche le certificat sans hurler, préviens quand le certificat a changé, et n'accepte pas le certificat auto-signé de Claude le geek pour signer le service Jabber de Google.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Grunt . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing". Évalué à 6.
Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Tu parles avec une vision très "web centrée". Ton formulaire il sert à quoi, finalement ? À publier un commentaire sur LinuxFR ? Avec NNTP (par exemple) le serveur n'a pas à se soucier de la forme des données, c'est le client qui respecte le format et va, par exemple, dire "cette adresse mail est bizarre, j'envoie quand même ?" ou "Attention, message vide !". Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile. Quoi que, y'a pas mal de poutrages de services Web qui se font en partie à cause de ça (path disclosure, injection SQL). Des failles récurrentes, inimaginables sur d'autres protocoles.
On a réinventé TCP/IP, super :)
Et par dessus ce HTTP, ben on code des applis, qui pourraient très bien être codées en utilisant directement TCP/IP et en tournant nativement chez l'utilisateur. Moins de ressources réseau et CPU gâchées. Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Ouais, j'avoue que ce gloubi-boulga m'échappe. Faut se lever de bonne heure pour comprendre et débugger une "application Web", c'est à dire, d'un point de vue système, un serveur Web qui sert des pages, lesquelles sont en fait des scripts qui tapent dans une base de données en s'authentifiant pour ensuite renvoyer du contenu HTML,et du javascript qui fait des trucs côté client afin que le client vienne faire d'autres trucs sur le serveur, ou des cookies.. Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Ça a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois. Ce qui est très différent de notifier l'utilisateur. Un débutant, je peux le guider au téléphone et lui confirmer (par exemple) le certificat auto-signé d'un serveur Jabber. Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber. Pire que ça : il n'aura même pas la possibilité d'accepter ce certificat uniquement pour un site précis, soit il fait confiance totale au propriétaire du certificat (y compris pour sa banque, ses mails..), soit il visite le site en version sans SSL. Super. Pendant ce temps, Gajim (c'est pas un projet aussi gros que Firefox hein) affiche le certificat sans hurler, préviens quand le certificat a changé, et n'accepte pas le certificat auto-signé de Claude le geek pour signer le service Jabber de Google.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.