Et puisqu’il faut un terme branché pour désigner tout ce mécanisme de mettre à jour la page avec des nouvelles données sans recharger la page en entier (truc de fou à l’époque !), le concept d’AJAX est né (Asynchronous JavaScript And XML - hé hé oui, on ne se débarrasse pas de XML comme ça, même dans le terme répandu, même quand XML n’est pas du tout impliqué. Parce que si des gens font bien transiter du XML de temps en temps, bien souvent, on utilise du JSON. Bien joué, Alex !).
XMLHttpRequest est anterieur de plusieurs années à json. Json a même était créé du fait de la popularité de XMLHttpRequest. Quand il a était implémenté par les navigateurs c'est bien du xml qui transité car c'était le seul format normalisé.
On peut lancer des requêtes pour envoyer des données au serveur, mais on peut aussi envoyer une requête de longue durée (long polling) et lire les données qui arrivent au fur et à mesure.
Le long polling c'est un peu plus subtile que ça. Il faut utiliser xhr, mais en gérant le timeout et en gérant une boucle. Tu tombe instantanément dans un callback hell avec xhr là où les promesses ou async/await vont être bien plus confortable à utiliser.
Mais le principe reste le même et tout ce que peut faire fetch peut être fait avec XMLHttpRequest[...]
Non, fetch peut être rerouté vers un worker par exemple, il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).
une sorte de keep-alive, quoi - et non, je ne sais pas pourquoi le keep-alive de TCP ne suffisait pas
Le keep-alive ne remonte pas jusqu'à l'application, il est global, il est de 2h généralement,...
De plus, les navigateurs, en HTTP 1.1, se limitent avec leur configuration par défaut à 6 connexions simultanées vers chaque hôte. Ce n’est pas le cas en HTTP 2, et donc peuvent surcharger plus facilement un serveur si celui-ci ne gère pas bien les connexions simultanées.
Je n'ai pas les moyens de le tester, mais je ne trouve rien qui va dans ce sens et ça m'étonne beaucoup. HTTP2 est là pour réduire le nombre de connexions pas l'augmenter. Qu'ils arrêtent de limiter le nombre de requêtes, ça ne m'étonnerait pas, mais le nombre de connexion ?
Je vois dans la doc de nginx des choses surprenantes comme :
In HTTP/2 and SPDY, each concurrent request is considered a separate connection.
[^] # Re: Java, flash
Posté par barmic 🦦 . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 8.
D'autres remarques :
XMLHttpRequest est anterieur de plusieurs années à json. Json a même était créé du fait de la popularité de XMLHttpRequest. Quand il a était implémenté par les navigateurs c'est bien du xml qui transité car c'était le seul format normalisé.
Le long polling c'est un peu plus subtile que ça. Il faut utiliser xhr, mais en gérant le timeout et en gérant une boucle. Tu tombe instantanément dans un callback hell avec xhr là où les promesses ou async/await vont être bien plus confortable à utiliser.
Non, fetch peut être rerouté vers un worker par exemple, il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).
Le keep-alive ne remonte pas jusqu'à l'application, il est global, il est de 2h généralement,...
Je n'ai pas les moyens de le tester, mais je ne trouve rien qui va dans ce sens et ça m'étonne beaucoup. HTTP2 est là pour réduire le nombre de connexions pas l'augmenter. Qu'ils arrêtent de limiter le nombre de requêtes, ça ne m'étonnerait pas, mais le nombre de connexion ?
Je vois dans la doc de nginx des choses surprenantes comme :
Documentation de la directive limit_conn
C'est pas ça qui t'a induit en erreur ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll