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 :
# SRV
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 Firwen (site web personnel) . Évalué à 2.
Tu as un lien à donner pour ça ? ça m'interesse
[^] # Re: SRV
Posté par rakoo (site web personnel) . É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 Firwen (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
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 :Je vais pouvoir :
toto.example.com.sur le port TCP 80 ;titi.example.com.sur le port TCP 80 ;On a donc là deux choses :
[^] # Re: SRV
Posté par Firwen (site web personnel) . Évalué à 2.
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.
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 Ife . Évalué à 9. Dernière modification le 19 février 2014 à 05:04.
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:
192.0.2.3va prendre autant de requêtes que192.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.Ça évite rien du tout. Tu as
web1.example.comà Roubaix etweb2.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 Firwen (site web personnel) . Évalué à 2. Dernière modification le 20 février 2014 à 08:47.
Le Round Robin fait ça aussi si le client le gère correctement, tout comme le SRV. Tu es juste de mauvaise fois.
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 rakoo (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 Larry Cow . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Firwen (site web personnel) . Évalué à 2. Dernière modification le 19 février 2014 à 00:17.
ç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 Ife . Évalué à 6.
De mon expérience, aucun navigateur n'a un tel comportement. Il prennent un enregistrement
Aau 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 Zenitram (site web personnel) . É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 kna . É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 barmic . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . É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 Joris Dedieu (site web personnel) . É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
[^] # Re: SRV
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 Joris Dedieu (site web personnel) . Évalué à 10. Dernière modification le 18 février 2014 à 17:00.
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 benoar . Évalué à 2.
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 espitall . É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 arnaudus . É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 Buf (Mastodon) . É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)
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 Firwen (site web personnel) . Évalué à 6. Dernière modification le 18 février 2014 à 15:03.
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 Zenitram (site web personnel) . Évalué à 4.
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 rakoo (site web personnel) . Évalué à 5. Dernière modification le 18 février 2014 à 16:44.
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 oinkoink_daotter . Évalué à 0. Dernière modification le 18 février 2014 à 17:28.
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 rakoo (site web personnel) . Évalué à 10.
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 BFG . Évalué à 6.
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 gnx . Évalué à 2.
Oui, c'est le match sécurité contre fonctionnalité. Sécurité absolue => zéro fonctionnalité.
[^] # Re: Nuance
Posté par claudex . É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 Firwen (site web personnel) . Évalué à 2.
ç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 groumly . É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 ariasuni . É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 Ife . Évalué à 5.
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 Joris Dedieu (site web personnel) . É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 :
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.