Discussion :

[sevyc64]

En gros le web c'est un peu comme l'euro, tout le monde sait que c'est pas optimal, que ça aurait pu être fait autrement, mais tout le monde dit qu'on est trop mouillé dedans pour en sortir sans casse.

Ouais, bof, faut pas exagérer non plus.

Il est très facile 20 ans après sa création et aux regards des dernières évolutions et utilisation, de critiquer la façon dont a été conçu le web.

Mais il y a 20 ans, lorsque le web a été inventé, le réseau Intranet tel que l'on le connait aujourd'hui, n'avait pas plus de 6-7 ans d’existence. C'était un réseau encore en cours de construction qui n'était utilisé à l'époque quasiment que pour du FTP, SMTP (mails) et NNTP (news, l'actuel usenet). Je suis sur que tu aurais dit à ceux qui ont inventer le web et notamment le http, qu'un jour, avec, on regarderais de la vidéo, on téléchargerait de très gros fichiers, on ferait du streaming, du web dynamique, etc, je pense qu'ils t'auraient bien rit au nez.

Évoluer oui, mais on ne peut pas faire une croix sur l'existant. La seule solution d'une évolution radicale serait d'inventer un nouveau protocole qui viendrait en parallèle de l'HTTP, en gardant à l'esprit qu'il faudrait plusieurs années pour son adoption (quand on voit le temps que ça prend de se débarrasser de IE6 et de l'IPv4 ...).

Et puis, le protocole n'est, au final, pas si mauvais que ça avec tout ce que l'on arrive à faire aujourd'hui alors qu'il n'était pas du tout imaginé pour ça au départ.

[_skip]

Je sais pas si tu te rends compte mais ton post me contredit sur aucun point. Je dis précisément dans mon post que le besoin a évolué et qu'on fait ce qu'on peut avec des technos qui sont ce qu'elles sont, tout en sachant que si on devait les reprendre à zéro dans le contexte actuel, on les ferait différemment.

Je critique juste le fait qu'on soit incapable de remettre en causes ces choses et de se dire que peut être qu'au lieu d'une Xème révision d'une spécification, on devrait peut être oser une nouvelle approche.
Bien sûr comme je l'ai dit, ce n'est pas facile à faire tant le compromis serait important mais en même temps je ne suis pas sûr qu'on tienne encore 50 ans sur cette même base en sachant que les exigences du milieu, elles, évoluent sans cesse vers plus d'interactions, plus de personalisations, plus d'état.

La remarque sur l'euro c'est un peu une quenelle lancée comme ça. Cependant ça illustre le fait que bien que ce soit pas forcément ce qu'il y a de mieux, on s'en débarrasse pas comme ça d'un revers de main.

[deathness]

Et puis, le protocole n'est, au final, pas si mauvais que ça avec tout ce que l'on arrive à faire aujourd'hui alors qu'il n'était pas du tout imaginé pour ça au départ.

C'est sur. Le truc à la base était quand même bien pensé.

Il faut se rendre compte de l'énorme différence de fréquentation a ses début à maintenant. C'est pareil pour le système DNS. Je crois qu'aucun protocole/logiciel n'a subi aussi peu d'amélioration en 20 ans d'existence et a su fonctionner bien au-delà de ce qui était prévisible (ne serait-ce juste qu'en terme du nombre de la population de site ou d'utilisateur).

[MiaowZedong]

(quand on voit le temps que ça prend de se débarrasser de IE6 et de l'IPv4 ...).

Hallucinant qu'en 2012 de grandes entreprises sont toujours victimes d'intrusions par les failles d'IE6. Dernièrement, Foxconn, qui croyait que "ça ne risque rien tant qu'on ne l'utilise que pour Intranet"

[BPiero]

Mais penser à résoudre le problème ne faciliterait pas la vie des dev Web, qui dans notre monde depuis 10 ans se pensent les rois du monde..

le problème c'est plutôt les dev pas web, qui croient que le jour ou ils s’intéressent à un domaine (le web en l’occurrence), ils vont révolutionner les habitudes de tout le monde simplement parce qu'ils ont participé à une discussion...
Ceci est ma dernière tentative d'explication:
Les cookies présentent un risque de confidentialité si ils sont mal utilisés, j'en convient.
Les cookies sont la manière la plus simple fiable et efficiente d'identifier les utilisateurs de manière unique.
On ne peux pas dire qu'il ne faut plus utiliser les cookies ou sinon:
Les voitures sont dangereuses et polluantes: plus personne ne doit conduire.
Le même problème (soulevé par les chercheurs microsoft) se pose avec les logs, la réponse est toujours la même.
En espérant clore ce débat stérile...
BPiero

[BPiero]

Évoluer oui, mais on ne peut pas faire une croix sur l'existant. La seule solution d'une évolution radicale serait d'inventer un nouveau protocole qui viendrait en parallèle de l'HTTP, en gardant à l'esprit qu'il faudrait plusieurs années pour son adoption (quand on voit le temps que ça prend de se débarrasser de IE6 et de l'IPv4 ...)

Non je peux pas laisser dire ça...
Qui connait les spécifications de HTTP?
Intéressez-vous à REST par exemple, et vous comprendrez que HTTP n'est pas utilisé aujourd'hui à plus d'un quart de ses possibilités.
C'est quand même dingue de vouloir remplacer un truc qui marche super bien et qui a un potentiel de fou simplement par méconnaissance du sujet.
Et à propos d'identification (ou authentification), saviez-vous que HTTP en propose un système, justement? Si vous voulez vraiment faire du cookie-free je pense que plutôt que réinventer la roue, vous pourriez vous renseigner sur ce qui existe.

j'avais pas vu la phrase qui suit, je suis un peu moins énervé

[sevyc64]

Évoluer oui, mais on ne peut pas faire une croix sur l'existant. La seule solution d'une évolution radicale serait d'inventer un nouveau protocole qui viendrait en parallèle de l'HTTP, en gardant à l'esprit qu'il faudrait plusieurs années pour son adoption (quand on voit le temps que ça prend de se débarrasser de IE6 et de l'IPv4 ...)

Non je peux pas laisser dire ça...
Qui connait les spécifications de HTTP?
Intéressez-vous à REST par exemple, et vous comprendrez que HTTP n'est pas utilisé aujourd'hui à plus d'un quart de ses possibilités.
C'est quand même dingue de vouloir remplacer un truc qui marche super bien et qui a un potentiel de fou simplement par méconnaissance du sujet.
Et à propos d'identification (ou authentification), saviez-vous que HTTP en propose un système, justement? Si vous voulez vraiment faire du cookie-free je pense que plutôt que réinventer la roue, vous pourriez vous renseigner sur ce qui existe.

j'avais pas vu la phrase qui suit, je suis un peu moins énervé

Et en quoi ce que j'ai dit est contradictoire ? Bien au contraire.

J'ai dit que :
- Soit on évolue à partir des bases que l'on connais déjà, et dans ce cas là on est bien obligé de se trainer l'existant
- Soit on avance de façon plus radicale. Dans ce cas il faut inventer quelque chose de nouveau. Mais que, même dans ce cas, on devra assurer la cohabitation avec l'existant pendant de nombreuses années encore.

Certainement que le protocole HTTP et les autres protocoles du net peuvent encore évoluer et certainement très largement. Il n'y a qu'à voir ce que a été l'introduction du DNS (puisqu'il a été cité plus haut).

DNS est une des clés pour ne pas dire la principale clé du développement web ces 15 dernières années. Sans DNS, on ne connaitrait pas l'internet tel que l'on le connais aujourd'hui.
Pourtant faut-il rappeler que le protocole DNS n'est, à la base, qu'une rustine pour cacher un des gros problèmes de l'internet qui ne sait pas géré, mais encore à l'heure actuelle, autre chose qu'un adressage par adresse IP ?

Le nom de domaine ne signifie rien sur internet, tout comme le nom d'une personne ne signifie rien dans une ville sans l'adresse postale (ie l'adresse ip) de son domicile.

Et même à la base c’était conçu pour de l'IPv4. Malgré tout, après le DNS, on a su rajouter aussi de l'IPv6. Que serait-il encore possible de faire demain ?

[tontonnux]

Ceci est ma dernière tentative d'explication:

Moi j'avais arrêté depuis un moment, mais je veux bien faire une dernière tentative pour te soutenir !

Les cookies présentent un risque de confidentialité si ils sont mal utilisés, j'en convient.

Et encore ! Au delà de la question de son utilisation, le simple changement de réglage par défaut dans les navigateurs refusant de créer un cookie pour un autre domaine que le domaine visité devrait grandement aider à régler ces problème (du point de vue cookie j'entends - la news qui a lancé la discussion montre bien que confidentialité et cookie sont loin d'être aussi directement liés que certains semblent croire -)

Les cookies sont la manière la plus simple fiable et efficiente d'identifier les utilisateurs de manière unique.
On ne peux pas dire qu'il ne faut plus utiliser les cookies ou sinon:
Les voitures sont dangereuses et polluantes: plus personne ne doit conduire.

Et que ceux qui n'en sont pas convaincus relisent l'ensemble des propositions qu'on peut trouver ci-dessus. Pour la plus part, ils ne font que réinventer le cookie en changeant son nom, ou pire, on propose de passer le tout dans l'url, ce qui de mon point de vue aurait des conséquences bien plus désastreuses pour la vie privée.

Honnêtement, je ne vois pas en quoi le cookie, dans sa définition, son mode de création peut être considéré comme un problème.

Il ne peut inscrire comme dit plus haut QUE des données qu'on a déjà transmises d'une manière ou d'une autre au serveur (la question de comment certaines sont collectées pose effectivement problème, mais surement pas le mode de stockage).
Un cookie est créé par un domaine et ne peut être accessible QUE par ce même domaine. Par exemple, si votre blog possède sur vous un cookie contenant les détails de votre vie sexuelle (oui, il faut avoir un problème pour faire ça, mais c'est pour expliquer), Facebook n'y aura JAMAIS accès (je prend cet exemple car il semble être le cauchemar de certains).
Ceux qui ont essayé de faire du Cross Domain Cookie en savent sûrement quelque chose.

Bref, le seul problème que pose le cookie à mes yeux (et personne ici qui crient à la mort du cookie n'a jusqu'à présent tenter de démontrer plus), c'est bien le fait que par défaut, les navigateurs laissent tout le monde écrire tout les cookies qu'ils veulent.
Mais ce n'est pas un problème dans le cookie (et encore moins dans le protocole HTTP -comment prétendre révolutionner HTTP quand on a pas compris le cookie ?-), c'est un problème... DES NAVIGATEURS !

Et les navigateurs influent ne sont pas si nombreux que ça. Alors oui, je maintiens que la solution passe par une législation qui oblige les éditeurs de navigateurs à aller dans ce sens.

[BPiero]

Et en quoi ce que j'ai dit est contradictoire ? Bien au contraire.

Yves,

Quelles évolutions souhaiterais-tu que subisse HTTP?
Je dit pas que c'est contradictoire, je dis que HTTP n'a pas besoin d'évoluer pour l'instant, donc c'est simplement moi qui te contredit.

HTTP supporte beaucoup plus de choses que tu ne semble le croire, mais ce qui est limitant c'est sa surcouche: HTML

Il y a eu de grandes avancées avec HTML5 (je suis le 1er à l'apprécier), mais on peut faire beaucoup mieux du point de vue du support du HTTP par HTML.

Par exemple, il a été proposé pour HTML5 d'ajouter les support des verbes PUT et DELETE déjà présent dans les specs HTTP1.1 (soit depuis 1999 donc plus de 10 ans après). Et bien malheureusement, le support de ces verbes n'a pas été retenu.

Pourquoi, je me le demande, mais ce qui limite l'évolution de HTML est un secret de polichinelle, c'est son support par les navigateurs, plus précisément internet explorer, faut-il ajouter que microsoft est un membre influant du w3c?

Donc je vais certainement me répéter mais pourquoi vouloir réinventer la roue?
BPiero

[Bluedeep]

ce qui limite l'évolution de HTML est un secret de polichinelle, c'est son support par les navigateurs, plus précisément internet explorer, faut-il ajouter que microsoft est un membre influant du w3c?

Bien sur ce ne peut être que la faute de Microsoft,parmis les 332 membres du W3C, qui inclut aussi la Mozilla Fundation, Apple et Google.

Il est donc évident que le principal responsable de ce retard ne peut être que Microsoft avec Internet Explorer, en aucun cas les autres éditeurs de navigateur.

[sevyc64]

Yves,

Quelles évolutions souhaiterais-tu que subisse HTTP?
Je dit pas que c'est contradictoire, je dis que HTTP n'a pas besoin d'évoluer pour l'instant, donc c'est simplement moi qui te contredit.

Ce n'est pas moi qui souhaite que HTTP évolue, c'est les intervenants précédents. Moi je ne fais que leur dire (à certains qui suggérer de pouvoir faire le contraire) que si l'on souhaite faire évoluer le HTTP on est quand même obligé de se trainer une partie de l'existant. Que si, au contraire on souhaite se débarrassé de l'existant, alors c'est pas HTTP qu'il faut faire évolué mais inventer quelque chose de nouveau. Mais que, de toute façon, même dans ce cas, HTTP restera quand même un certain pour raison de compatibilité.
Ça fait 3 fois que je le dis, j'ai l'impression de radoter.

HTTP supporte beaucoup plus de choses que tu ne semble le croire,

Je ne sais pas ce que eut supporter en core le HTTP, et à vrai dire, je m'en contre fiche. Je sais surtout qu'il supporte déjà bien plus que ce qui été imaginé lorsqu'il a été conçu, et ce, malgré les faiblesses qui lui sont reconnue de façon quasiment unanime.

mais ce qui est limitant c'est sa surcouche: HTML

Il y a eu de grandes avancées avec HTML5 (je suis le 1er à l'apprécier), mais on peut faire beaucoup mieux du point de vue du support du HTTP par HTML.

Par exemple, il a été proposé pour HTML5 d'ajouter les support des verbes PUT et DELETE déjà présent dans les specs HTTP1.1 (soit depuis 1999 donc plus de 10 ans après). Et bien malheureusement, le support de ces verbes n'a pas été retenu.

Pourquoi, je me le demande, mais ce qui limite l'évolution de HTML est un secret de polichinelle, c'est son support par les navigateurs, plus précisément internet explorer, faut-il ajouter que microsoft est un membre influant du w3c?

Donc je vais certainement me répéter mais pourquoi vouloir réinventer la roue?
BPiero

Attention quand même à ne pas mélanger, ni faire d’amalgame entre HTTP et HTML. Ce sont 2 choses totalement différentes.
HTTP est un protocole de communication. HTML n'est qu'un vulgaire format de fichier (certains appellent ça langage) au même titre que le format PDF, le format DOC de Word, etc.

Si 90% du traffic HTTP à pour origine du HTML, si 99% du HTML est transporter par du HTTP, le HTTP n'a pas besoin du HTML pour fonctionner, le HTML peut très bien être transporter par tout autre forme de média.

Et ce n'est pas une quelconque évolution du HTML qui corrigera les lacunes du HTTP. Tout au plus peut-elle les compensées, ce qui est déjà fait depuis longtemps d'ailleurs.

[BPiero]

Bien sur ce ne peut être que la faute de Microsoft,parmis les 332 membres du W3C, qui inclut aussi la Mozilla Fundation, Apple et Google.

Il est donc évident que le principal responsable de ce retard ne peut être que Microsoft avec Internet Explorer, en aucun cas les autres éditeurs de navigateur.

Bon ok j'ai peut-être un peu abusé la dessus...
C pour ça les -5

[BPiero]

Je sais surtout qu'il supporte déjà bien plus que ce qui été imaginé lorsqu'il a été conçu, et ce, malgré les faiblesses qui lui sont reconnue de façon quasiment unanime.

Quelles sont ces faiblesses?
Ne sont elles pas dans la tête des gens plutôt?
Je me demande où tu as été péché ça?

Attention quand même à ne pas mélanger, ni faire d’amalgame entre HTTP et HTML. Ce sont 2 choses totalement différentes.

Merci je suis aussi un dev web...

HTTP est un protocole de communication. HTML n'est qu'un vulgaire format de fichier (certains appellent ça langage) au même titre que le format PDF, le format DOC de Word, etc.

Bon alors pourquoi l'attribut action d'un form peut prendre les valeurs get ou post?
Tu ne semble pas comprendre que HTML a été conçu pour fonctionner sur HTTP (les deux ont d'ailleurs été inventé par Tim Berners Lee)
Je fais parti de ces gens qui appellent ça un langage, plus précisément un langage de balisage.

Et ce n'est pas une quelconque évolution du HTML qui corrigera les lacunes du HTTP. Tout au plus peut-elle les compensées, ce qui est déjà fait depuis longtemps d'ailleurs.

Je t'ai pourtant donné un exemple du contraire dans mon post précédent.
M'as tu lu?

BPiero

[sevyc64]

Quelles sont ces faiblesses?
Ne sont elles pas dans la tête des gens plutôt?
Je me demande où tu as été péché ça?

Quelques unes ont été citées dans les 4 pages de dialogue de sourds qui précèdent

Tu ne semble pas comprendre que HTML a été conçu pour fonctionner sur HTTP (les deux ont d'ailleurs été inventé par Tim Berners Lee).

Que le HTML ait été conçu pour fonctionner (principalement) sur le HTTP, qu'il ait été inventé par la même personne, il n'en reste pas moins que ce sont 2 choses totalement différentes et indépendantes l'une de l'autre. Ils n'ont pas besoin l'un de l'autre pour fonctionner chacun de leur coté, même si leur utilisation est liée dans la très grande majorité des cas.

Je fais parti de ces gens qui appellent ça un langage, plus précisément un langage de balisage.

Désolé, j'aurais dû le préciser, je parlais d'un langage de programmation, en clin d'oeil aux trolls que l'on voit régulièrement sur ce point.
Un langage de balisage, oui, je suis d'accord avec toi, au même titre que XML dont il est une déclinaison. Un langage de programmation, il y a effectivement matière à débat.

Je t'ai pourtant donné un exemple du contraire dans mon post précédent.
M'as tu lu?

Oui, je t'ai lu, mais pas toi visiblement.
Ou alors tu n'as pas compris la nuance que j'ai apporté.
Quelques soient les évolutions que tu apporteras au HTML, elles ne corrigeront jamais les faiblesses ou les manques (appelles- les comme tu veux) du protocole HTTP.
Par contre, oui, certaines évolutions peuvent être faite pour palier (compenser, j'avais dit) ces dites faiblesses, de sorte qu'à l'utilisation, cette faiblesse ne soit plus visible, mais ça ne la corrige pas pour autant.
C'est comme si je te disais que ta voiture n'a pas de clignoteur, alors tu agite une lampe par la fenêtre lorsque tu veux tourner. Tu compense pour indiquer quand même que tu tourne, mais ça ne corrige en rien le fait que ta voiture n'a pas de clignoteur.