Journal HTTP2, le protocole écrit comme une loi américaine

Posté par (page perso) . Licence CC by-sa
13
18
fév.
2014

Bonjour Nal,

HTTP2 est le petit nom du protocole censé remplacer notre bon vieux HTTP. D'après Wikipédia,

Goals for HTTP 2.0 are to improve the overall performance of the protocol while maintaining full backwards compatibility with the transaction semantics of HTTP 1.1.

Ce qui donne en bon françois : Le but avec HTTP 2.0 est d'améliorer globalement les performances du protocole tout en maintenant une compatibilité complète avec la sémantique des transactions.

Une nouvelle version du brouillon a été proposée le 6 février. Le mieux pour en parler est via un article qui explique en long et en large que ce brouillon met en bordel le fonctionnement des redirections. Cet article explique bien mieux que moi le souci, mais en gros on passe de

  • 301 : Redirection permanente "oublie cette URL et prends plutôt celle-là", le navigateur garde la méthode d'envoi (1) utilisée ;
  • 302 : trop d'implémentations différentes dans les navigateurs donc non utilisé ;
  • 303 : Redirection "Tu devrais aller voir là-bas", la prochaine méthode d'envoi faite par le navigateur doit être GET ;
  • 307 : Redirection temporaire "pour aujourd'hui, il faut aller voir ailleurs, mais ton URL va refonctionner normalement bientôt", le navigateur garde la méthode d'envoi (c'est comme ça que 302 devrait fonctionner) ;
  • 308 : expérimental, utilisé pour l'upload par les services Google dans le sens "j'ai bien reçu une partie du fichier, continue de m'en envoyer" (pour éviter d'envoyer un énorme fichier d'un coup), le navigateur garde la méthode d'envoi ;

(1) Request Method, ici GET ou POST.

à :

  • 301 : Surprise surprise ! Et aucun moyen de savoir s'il faut changer ou non la méthode d'envoi.
  • 302 : Surprise surprise ! même chose.
  • 303 : aucun changement par rapport à avant.
  • 307 : aucun changement par rapport à avant.
  • 308 : le comportement de l'ancien 301.

Je rappelle l'objectif du nouveau protocole :

Goals for HTTP 2.0 are to improve the overall performance of the protocol while maintaining full backwards compatibility with the transaction semantics of HTTP 1.1.

Je vous invite à nouveau à lire l'article détaillé pour plus de détails croustillants : http://insanecoding.blogspot.fr/2014/02/http-308-incompetence-expected.html

Pour ceux qui ne sont pas intéressés, voici une nimage :

HTTP2 CODE 301. POST/GET? Surprise me.

  • # SRV

    Posté par (page perso) . Évalué à 10.

    Moi, ce qui m'agace surtout avec HTTP2, c'est qu'ils ont laissé tomber l'idée d'utiliser des enregistrements SRV pour fournir une redondance et une répartition de charge simple. HTTP reste trop fossilisé pour évoluer vraiment, en somme.

    • [^] # Re: SRV

      Posté par (page perso) . Évalué à 2.

      Tu as un lien à donner pour ça ? ça m'interesse

      • [^] # Re: SRV

        Posté par (page perso) . Évalué à 6.

        Remplace XMPP par HTTP, c'est presque pareil (La différence est qu'en XMPP il y a besoin de 2 ports différents pour que ça marche, en HTTP un seul suffit).

        • [^] # Re: SRV

          Posté par (page perso) . Évalué à -3.

          Je connais le principe, pour XMPP. Mais en l'occurence ce type de mapping permet de faire une association A ou AAAA par protocol sans passer par un sub domaine.

          Sauf si je loupe vraiment qqchose, ça n'aide strictement rien pour la redondance ou la montée en charge comparé à des enregistrement A classiques.

          • [^] # Re: SRV

            Posté par (page perso) . Évalué à 10.

            Sauf si je loupe vraiment qqchose

            Tu dois vraiment louper quelque chose. Si je cherche à charger une page http://example.com/sarass , je demande les enregistrements DNS _http._tcp.example.com. Si j'obtiens cette réponse :

            _http._tcp.example.com. SRV 10 70 80 toto.example.com.
            _http._tcp.example.com. SRV 10 30 80 titi.example.com.
            _http._tcp.example.com. SRV 20 70 80 tata.example.com.
            

            Je vais pouvoir :

            1. essayer de me connecter sur l'un des serveurs de priorité 10, au hasard selon leurs poids respectifs, donc :
              1. tirer un nombre aléatoire entre 0 inclus et 100 exclus ;
              2. s'il est inférieur ou égal à 70, me connecter au serveur toto.example.com. sur le port TCP 80 ;
              3. s'il est strictement supérieur à 70, me connecter au serveur titi.example.com. sur le port TCP 80 ;
            2. se cette première tentative échoue, essayer de me connecter sur le serveur de priorité 20.

            On a donc là deux choses :

            1. de la répartition de charge, puisque, de façon aléatoire pondérée, les clients vont se connecter sur un serveur ou l'autre : aujourd'hui, pour faire la même chose on met plein d'enregistrements DNS A et AAAA, en pondérant à coup de répétitions… ;
            2. de la redondance, puisque, si la tentative de connexion à un serveur de haute priorité a échoué, on essaie les priorités plus basses : aujourd'hui, pour faire la même chose on met des dispositifs dédiés qui constituent aux-mêmes des SPOF, qu'on double éventuellement mais la connexion à Internet reste toujours un SPOF, qu'on ne peut éventuellement contourner qu'en faisant du routage BGP, ce qui n'est vraiment pas à la portée de tout le monde.
            • [^] # Re: SRV

              Posté par (page perso) . Évalué à 2.

              de la répartition de charge, puisque, de façon aléatoire pondérée, les clients vont se connecter sur un serveur ou l'autre : aujourd'hui, pour faire la même chose on met plein d'enregistrements DNS A et AAAA, en pondérant à coup de répétitions… ;

              Yep, D'où ma question. Habituellement, on fait ça avec un Round-Robin sur les enregistrement A et AAAA et ça remplace ça sans problème.
              J'ignorais que le record SRV supportait un champ priorité, thx.

              de la redondance, puisque, si la tentative de connexion à un serveur de haute priorité a échoué, on essaie les priorités plus basses : aujourd'hui, pour faire la même chose on met des dispositifs dédiés qui constituent aux-mêmes des SPOF, qu'on double éventuellement mais la connexion à Internet reste toujours un SPOF, qu'on ne peut éventuellement contourner qu'en faisant du routage BGP, ce qui n'est vraiment pas à la portée de tout le monde

              Une aternative à ça est d'avoir un TTL faible pour les enregistrement associé à un DNS load balancer dynamique, qui détecte les serveurs qui partent en sucette. Ce n'est pas parfait, mais ça évite déja les désastres.

              • [^] # Re: SRV

                Posté par . Évalué à 9. Dernière modification le 19/02/14 à 05:04.

                Yep, D'où ma question. Habituellement, on fait ça avec un Round-Robin sur les enregistrement A et AAAA et ça remplace ça sans problème.

                Les enregistrement SRV gérent une pondération. La distribution en tourniquet (round robin) ne le supporte pas. Théoriquement, si tu as les enregistrement DNS suivant:

                www.example.com A 192.0.2.1
                www.example.com A 192.0.2.2
                www.example.com A 192.0.2.3
                

                192.0.2.3 va prendre autant de requêtes que 192.0.2.1, pourtant, ce premier est mon serveur de courriel. J'aimerai qu'il ne prenne que 10% des requêtes. Impossible de faire ça avec les enregistrements A et AAAA.

                Une aternative à ça est d'avoir un TTL faible pour les enregistrement associé à un DNS load balancer dynamique, qui détecte les serveurs qui partent en sucette. Ce n'est pas parfait, mais ça évite déja les désastres.

                Ça évite rien du tout. Tu as web1.example.com à Roubaix et web2.example.com à Amsterdam. Un matin, un routeur en Angleterre pète, donc toutes les connexions vers Roubaix depuis New York ne peuvent pas être établies, parce que l'entreprise a Roubaix un réseau un peu merdique qui n'est pas résistant aux désastres.
                Tout tes serveurs (et ton DNS) sont en Europe, donc ils peuvent contacter Roubaix sans aucun problème, et pensent que ton serveur est toujours accessible. Du coup, tes DNS (même avec ton TTL de 5 minute) contiennent toujours web1.example.com.

                Avec SRV, ton utilisateur à Chicago essaie de se connecter à web1, il y arrive pas il se connecte à web2, et accède ton site web.

                La contrepartie avec ça, c'est que le temps d'arrivé du premier octet est de 1 ou 2 secondes au lieu de 250 ms. Mais c'est toujours mieux que un temps d'arrivé du premier octet de… Que dalle, ya pas de premier octet!

                Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

                • [^] # Re: SRV

                  Posté par (page perso) . Évalué à 2. Dernière modification le 20/02/14 à 08:47.

                  Ça évite rien du tout. Tu as web1.example.com à Roubaix et web2.example.com à Amsterdam.

                  Le Round Robin fait ça aussi si le client le gère correctement, tout comme le SRV. Tu es juste de mauvaise fois.

                  192.0.2.3 va prendre autant de requêtes que 192.0.2.1, pourtant, ce premier est mon serveur de courriel. J'aimerai qu'il ne prenne que 10% des requêtes. Impossible de faire ça avec les enregistrements A et AAAA.

                  Si je comprends bien, ta seule excuse est de pouvoir exposer un serveur sensible tout en priant pour que 10% de la charge ne le détruise pas. ça m'a l'air hors pair comme technique en effet.

          • [^] # Re: SRV

            Posté par (page perso) . Évalué à 4.

            Oui, pardon, la partie sur la redondance peut être vue sur wikipedia.

            Pour faire simple, quand ton solveur DNS va faire la requête, il va récupérer plusieurs A/AAAA possibles, chacun avec suffisamment d'indicateurs pour que les clients ne tapent pas sur la même machine en même temps, tout en restant suffisamment simple pour que le mécanisme de caches de DNS ne pose pas trop de problèmes. En gros, du load-balancing de base.

            • [^] # Re: SRV

              Posté par . Évalué à 2.

              Cela n'est pas déjà possible avec plusieurs IP pour le même nom ?

              "La première sécurité est la liberté"

              • [^] # Re: SRV

                Posté par . Évalué à 6.

                Certes, mais au prix d'une bidouille rajoutant une quantité variable de travail au serveur (pas grand chose en HTTP, déjà nettement plus en HTTPS). L'avantage d'avoir un support des enregistrements SRV, ça serait d'avoir du "port-based-virtualhosting" transparent pour le client.

              • [^] # Re: SRV

                Posté par (page perso) . Évalué à 5.

                Non. Une répartition de charge est possible de cette façon, quoique manquant sérieusement de souplesse, en revanche cela ne permet absolument pas de fournir une redondance.

                • [^] # Re: SRV

                  Posté par (page perso) . Évalué à 2. Dernière modification le 19/02/14 à 00:17.

                  en revanche cela ne permet absolument pas de fournir une redondance.

                  ça permet de faire de la redondance dans les deux cas si le client n'est pas assez gland pour considérer uniquement un enregistrement.

                  Dans le cas d'une pool d'enregistrement AAAA/A, tu as une liste de serveurs en Roud-Robin pour la "failover".
                  Dans le cas d'une pool d'enregistrement SRV, tu as une liste de serveurs ordonnée pour la "failover".

                  La seul différence c'est que SRV t’autoriseraient hypothétiquement à définir une priorité. Mais j'ai envie de te dire, la priorité tu t'en tamponnes joyeusement dans le cas de HTTP.

                  • [^] # Re: SRV

                    Posté par . Évalué à 6.

                    Dans le cas d'une pool d'enregistrement AAAA/A, tu as une liste de serveurs en Roud-Robin pour la "failover".

                    De mon expérience, aucun navigateur n'a un tel comportement. Il prennent un enregistrement A au hasard. Essai de se connecter. N'y arrive pas, le site est considéré inaccessible.

                    Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

                    • [^] # Re: SRV

                      Posté par (page perso) . Évalué à 3.

                      ce n'est pas ce que dit mon expérience, mais pas du tout, c'est même pour ça que les DNS envoient deux IP (ou plus) en Round robin : le navigateur essaye la première IP (pas au hasard, seulement la première, par contre les serveurs intermédiaires refont un round Robien aussi donc tu ne sais jamais laquelle sera la première envoyée même si tu met toujours une seule IP en premier dans tes DNS donc pas de GeoIP avec redondance), si ça marche pas ils essayent la 2ème. Sur tous les navigateurs.

                      • [^] # Re: SRV

                        Posté par . Évalué à 1.

                        Mon expérience disait le contraire, mais un test rapide te donne raison.
                        Je pense alors qu'il doit y avoir des vieux brouteurs qui s'arrêtent au premier fail, et une rapide recherche me le confirme : http://www.nber.org/sys-admin/dns-failover.html

    • [^] # Re: SRV

      Posté par . Évalué à 1.

      Moi, ce qui m'agace surtout avec HTTP2, c'est qu'ils ont laissé tomber l'idée d'utiliser des enregistrements SRV pour fournir une redondance et une répartition de charge simple.

      Pourquoi ? Ils ont émis cette idée à un moment ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: SRV

        Posté par (page perso) . Évalué à 2.

        S'ils ne l'ont pas fait, c'est encore plus décevant que je ne pouvais l'imaginer.

        • [^] # Re: SRV

          Posté par (page perso) . Évalué à 6.

          Si ils l'on fait. Voir par exemple http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/1149.html. Il y a eu de long débats à ce sujet. Ils ont d'ailleurs laissé la porte ouverte pour ce point (A client can learn that a particular server supports HTTP/2 by other means).

          Le problème est que l'enregistrement SRV ne répond pas à tous les problèmes (notamment l'upgrade) et surtout que se mécanisme induit une dépendance entre http et un autre protocole (DNS).

          http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/1156.html

          Or not applicable. Think about how many web developers connect to
          $IP:$PORT during their development phase and have tens of available
          ip:port combinations to test various software versions/variants
          without any DNS being aware of them.

          We must never forget that what made HTTP succeed is also the fact that
          it's self-contained, does not require additional side-band protocols,
          works end-to-end over a single connection and is 100% NAT-friendly by
          not storing any IP-related information anywhere.

          • [^] # Re: SRV

            Posté par (page perso) . Évalué à -2.

            Mon Dieu, l'argument débile… Dépendance sur le DNS : genre ce n'est pas déjà largement le cas… Cas où les ports différents du 80 et du 443 sont bloqués : il suffit de recommander l'usage de ces deux ports…

            • [^] # Re: SRV

              Posté par (page perso) . Évalué à 10. Dernière modification le 18/02/14 à 17:00.

              Mon Dieu, l'argument débile… Dépendance sur le DNS

              C'est un point de vue lapidaire, comme le reste de ce fil par ailleurs. Tu affirmes que personne n'a jamais discuté du fait d'adopter le SRV pour http. Je te montres juste que c'est complètement faux. En l'occurrence, il semble bien que ce soit toi qui ait du mal à en discuter …

              Le SRV n'a simplement pas été retenu pour diverses raisons. Notamment parce que la fait de dépendre d'une information sur l'IP a semblé à certains contradictoire avec l'esprit et la force de HTTP comme le disait Willy Tarreau dans le message que j'ai cité. Un autre aspect est l'overhead induit par le SRV notamment lorsqu'il n'existe pas. C'est très bien décris dans ce draft : http://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01#appendix-A qui tu le notera par ailleurs s’intéresse exclusivement à la question de savoir comment publier les informations concernant les serveurs HTTP dans les DNS.

              Donc, oui ça a été discuté, oui ça a été débattu, oui des gens s'y intéressent et cherchent à trouver des solutions à un problème qui n'est pas si simple et qui a de nombreuses implications.

              Maintenant si tu préfères incanter comme chaque fois qu'il y a un fil sur HTTP, je ne viendrai plus polluer tes fils sur les enregistrements SRV avec des informations qui a minima pourraient s’avérer intéressantes pour les personnes qui cherchent à réfléchir au sujet.

              Mes deux cents
              Joris

          • [^] # Re: SRV

            Posté par . Évalué à 2.

            et surtout que se mécanisme induit une dépendance entre http et un autre protocole (DNS).

            Heu… je ne sais pas si tu appelles ça une « dépendance », mais depuis longtemps (HTTP 1.1 !) on doit inclure le header "Host". Ton protocole va donc t'afficher un contenu différent en fonction du nom utilisé, et ton IP seule ne sera pas suffisante pour faire fonctionner ton site correctement.

            Ajouter un enregistrement SRV à consulter, ça n'est pas la mort : on le fait déjà avec le AAAA. Et l'argument que j'ai vu ailleurs que « ça va entraîner plein de latences à cause des indirections DNS » est débile car prenant exemple sur un cas tordu, qui sera exactement le même qu'aujourd'hui quand quelqu'un veut faire un enchaînement de CNAME bizarre.

  • # Nuance

    Posté par . Évalué à 10.

    Le lien vers insanecoding.blogspot.fr a aussi été posté sur HN : https://news.ycombinator.com/item?id=7249193

    On peut y lire dans les commentaires quelques réserves. Grosso modo, les codes 301 et 302 ont été volontairement "mal" implémentés dans chromium et firefox au niveau du changement de la méthode d'envoi afin de reproduire le fonctionnement de IE qui était en position de force !
    Dans HTTP 2.0 le but étant d'écrire un standard ne cassant pas le fonctionnement actuel (et non la norme actuelle, ce qui est bien différent !), le choix a été de dire on fait coller la nouvelle norme au fonctionnement majoritaire actuel des codes 301 et 302 (l'article veut faire croire l'inverse, mais c'est faux) et de repartir sur une base propre avec de nouveaux codes d'erreurs.

    Bonus (trouvé dans les commentaires sur HN), un lien vers le code de chromium sur la gestion des codes 301 et 302 avec un joli commentaire explicatif : https://code.google.com/p/chromium/codesearch#chromium/src/net/url_request/url_request.cc&q=ComputeMethodForRedirect&sq=package:chromium&l=570

    • [^] # Re: Nuance

      Posté par . Évalué à 6.

      D'une manière générale, je n'aime pas trop ces posts de blogs «le monde entier est rempli de cons, spécialement les instances décisionnaires, alors que je suis un Dieu et que j'ai la science infuse». J'imagine que les décisions au sein d'un comité de standardisation ne sont pas prises au hasard, elles sont le résultat de débats techniques et politiques, souvent d'ailleurs sous forme de compromis entre plusieurs visions irréconciliables.

      Au passage, j'ai beaucoup de mal à comprendre comment HTTP2 pourrait casser le web, comme l'auteur du post le sous-entend. Au pire du pire du pire, le navigateur risque de renvoyer une erreur explicite au lieu de rediriger vers la bonne URL (et dans la plupart des cas, le comportement du navigateur sera conforme). J'ai un peu l'impression qu'il y a des sujets plus graves dans la vie que la normalisation pas carrée des erreurs 301 et 302…

      • [^] # Re: Nuance

        Posté par . Évalué à 6.

        J'ai fait 2-3 tests, voici où on en est aujourd'hui (pour les dernières version de tous les navigateurs cités)

        • sur un 301, Firefox et Chrome changent le POST en GET. IE garde le POST, mais n'affiche aucun avertissement (alors que c'est exigé par la spec)
        • sur un 302, tous les browsers changent le POST en GET, et c'est le comportement attendu par la plupart des frameworks web (mais ça ne correspond pas à la spec)
        • le 303 est traité correctement partout (mais peut éventuellement poser problème avec les très vieux browsers)
        • avec un 307, tous les browsers conservent le POST, mais seul Firefox affiche un avertissement, conformément à la spec.

        Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile. En pratique, on ne retourne jamais de 301 après un POST.

        Maintenant, concernant la spec HTTP2, à mon avis, ils cherchent à coller à la pratique actuelle plutôt qu'à suivre ce qui est dit dans la spec HTTP 1.1 (et que personne ne respecte)

        • [^] # Re: Nuance

          Posté par (page perso) . Évalué à 6. Dernière modification le 18/02/14 à 15:03.

          Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile

          Toutes les API REST ( amazon S3 entre autres ) qui autorisent un remplacement PUT par un Post + header pour passer au travers des firewalls nazis et des proxys configurés par un admin alcoolique qui refuses les requêtes "PUT".

          Dans le cas d'un système de stockage distribué, tu as tout interet a rediriger un "PUT" ( donc un POST :D ) quelque-part d'autre ( généralement au plus proche de ton disk node )

        • [^] # Re: Nuance

          Posté par (page perso) . Évalué à 4.

          Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile.

          Par exemple, une URL qui a changé? (je dis ça comme ça…)
          Perso je comprend la spec 301/302 comme "fait comme avant, mais avec cette nouvelle URL, et si c'est 301 tu gardes ça en mémoire", donc POST devrait rester POST, et trouver un autre code pour dire "OK, j'ai fait ce qu'il fallait par rapport à ton POST, maitenant je voudrais que tu fasses telle commande sur telle page".
          Mais bon, maintenant qu'on a toutes ces implémentations qui font comme elles veulent car "j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile"…

        • [^] # Re: Nuance

          Posté par (page perso) . Évalué à 5. Dernière modification le 18/02/14 à 16:44.

          Dans tous les cas, j'ai beaucoup de mal à imaginer une situation dans laquelle le comportement POST-redirect-POST est utile

          Il me semblait que la force de HTTP était d’être stateless. Tant que le serveur ne t'a pas dit que tout s'est bien passe correctement, pour moi, tu devrais considérer que tu dois recommencer de zéro. Ca veut dire que le seul truc que tu changes, c'est l'url. Mais c'est juste mon avis.

          • [^] # Re: Nuance

            Posté par . Évalué à 0. Dernière modification le 18/02/14 à 17:28.

            Il me semblait que la force de HTTP était d’être stateless.

            C'est une caractéristique, certes. De la à dire à que c'est une force … Je qualifierais ça plutôt de boulet, de nos jours, perso, mais ce n'est que mon avis à moi que j'ai et qui n'engage que moi.

            • [^] # Re: Nuance

              Posté par (page perso) . Évalué à 10.

              ce n'est que mon avis à moi

              Bon, on peut digresser alors :)

              Pour moi HTTP est un protocole qui a été pense pour le stateless, et qui est simple a utiliser dans ces cas la. C'est d'ailleurs une solution bien pratique au mobile dans le cas de XMPP: plutot que d'essayer de garder une socket ouverte tout le temps, un client peut communiquer de temps en temps avec le serveur pour récupérer le dernier statut de la session (lire ce post).

              Au fil du temps, HTTP est devenu de plus en plus axé session (surtout dans les usages), ce qui le travestit de plus en plus (le point d'orgue étant pour moi websocket, qui fonctionnellement n'est rien de plus que TCP. Ah si, ça permet de contourner tous les pare-feu nazis qui n'acceptent que le HTTP sur le port 80).

              La solution la plus propre est pour moi d'utiliser un protocole qui fait ce qu'on a envie de faire (par exemple XMPP ou BEEP, qui permet de faire une communication full-duplex). Mais malheureusement c'est a l’opposé total de la vie réelle et des utilisateurs qui veulent le minimum de changements nécessaires pour avoir accès aux nouvelles fonctionnalités… et quelque part ils ont raison.

              • [^] # Re: Nuance

                Posté par . Évalué à 6.

                Ah si, ça permet de contourner tous les pare-feu nazis qui n'acceptent que le HTTP sur le port 80

                Dit autrement, WebSockets ne sert qu'à violer les règles de sécurité mises en place (sans juger de la légitimité de ces règles).

                Pourquoi les pare-feux bloquent-ils tout ce qui n'est pas sur le port 80 ?
                Quelles que soient les raisons, ce qu'ils ont voulu bloquer finira par passer par le port 80, et ils devront alors analyser le trafic pour faire un blocage plus fin. Alors, on ajoutera une autre couche par dessus WebSockets. Le problème n'a fait qu'être déplacé, en ajoutant une couche en plus entre les deux.

                Ce sont sans doute les mêmes qui conçoivent chacun des deux côtés de cet affrontement, mais les motivations de posséder ces multiples personnalités m'échappent.

                • [^] # Re: Nuance

                  Posté par . Évalué à 2.

                  Oui, c'est le match sécurité contre fonctionnalité. Sécurité absolue => zéro fonctionnalité.

                • [^] # Re: Nuance

                  Posté par (page perso) . Évalué à 3.

                  Mais on peut très bien le faire sans WebSocket (d'ailleurs, ça se fait) avec Comet. WebSocket, c'est juste un moyen rendre Comet plus propre et plus performant.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Nuance

              Posté par (page perso) . Évalué à 2.

              C'est une caractéristique, certes. De la à dire à que c'est une force … Je qualifierais ça plutôt de boulet, de nos jours, perso, mais ce n'est que mon avis à moi que j'ai et qui n'engage que moi.

              ça se discute, mais si tu mets de coté les problèmes de perfs issues du fonctionnement de TCP, c'est plutot une force
              - Une force en cas de mobilité, tu peux migrer d'un réseau à l'autre entre deux requètes sans soucis.
              - Une force pour faire du load balancing, dispatcher des queries stateless dans une pool est bien aisée que monitorer des connexions.
              - Une force en cas d'attaque DDOS, tout ce qui est statefull oblige impérativement un état sur serveur.

              • [^] # Re: Nuance

                Posté par . Évalué à 6.

                Rajoutes: pour les clients riches (applis natives ou html5/js fancy), ca fait vachement plus de sens de conserver l'etat cote client, vu que de toutes facons le client va conserver l'etat, et ca evite de jongler avec des sessions des bois qu'il faut repliquer a travers ton cluster.

                Ca permet de limiter ta session a tres exactement rien du tout, et de passer un token oauth2 entre requetes pour l'authentification (et encore, si t'en as besoin). 100% stateless, ton serveur scale vachement plus simplement et tu te simplifies vachement la vie.

                Quand tu regardes les principes fondateurs de rest, c'est meme explicitement dit que c'est au client de gerer ce merdier.
                Les problemes apparaissent quand tu design ton serveur pour etre stateful, et effectivement avec du web a la papa, c'est dur de faire autrement.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # SPDY

    Posté par (page perso) . Évalué à 7.

    Ça change quoi par rapport à SPDY? (puisque HTTP2 est inspiré de SPDY)

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: SPDY

      Posté par . Évalué à 5.

      • SPDY est SSL seulement.
      • SPDY n'est pas rétro-compatible. (Les serveurs web utilisent la négociation SSL pour savoir si le client supporte spdy ou non)
      • SPDY est google. Google is evil.

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

  • # Confusion

    Posté par (page perso) . Évalué à 10.

    Le draft en question ne fait pas partie de http/2.0

    Le groupe de travail http-bis fait en effet deux choses :

    • spécifier http 2.0
    • moderniser la sémantique de http (réviser http 1.1).

    Ce draft fait partie de la seconde activité du groupe. HTTP/2.0 ne touche en aucun cas à la sémantique de HTTP mais s'occupe du transport.

    http://trac.tools.ietf.org/wg/httpbis/trac/wiki

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.