XMLHttpRequest est anterieur de plusieurs années à json
D'accord, mais tu n'étais pas obligé de transmettre du XML avec. Tu pouvais transmettre des données plain text, des scripts javascript... bref, l'objet n'a rien de spécifique à XML et en programmation on a quand même pas mal l'habitude de séparer les probèmes...
Ce n'est vraiment pas moi qui le dit, pour le coup, je n'ai rien inventé c'est la personne qui a conçu XmlHttpRequest (premier lien de la dépêche) !
I got in touch with Jean Paoli who was running that team at the time and we pretty quickly struck a deal to ship the thing as part of the MSXML library. Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).
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.
C'est décrit dans la dépêche... qui reste une dépêche, pas une doc.
Non, fetch peut être rerouté vers un worker par exemple
Donc si tu dis que fetch est utilisable dans un worker, ce n'est pas un contre exemple d'un truc que fetch peut faire et pas XMLHttpRequest
il y a un travail en cours pour pouvoir annuler des requêtes (particulièrement utile pour ton scope de requêtes longues).
Je ne doute pas que dans le futur, les APIs vont continuer à évoluer et je ne serais pas étonné si fetch finissait par faire des choses que XmlHttpRequest ne fait pas.
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
À noter que le mécanisme de keep-alive ne remonte pas jusqu'au code utilisant l'objet WebSocket (ce qui ne contredit en rien ton affirmation, on est tout à fait d'accord).
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 ?
Tu as raison, j'ai utilisé le mot « connexion » un peu négligemment mais ça ne change pas le sens de ce passage ni le raisonnement autour.
Le passage de la doc de Nginx n'a rien de surprenant : il avertit simplement que le paramètre dont il est question n'a pas exactement le même sens en HTTP 1.1 qu'en HTTP 2, justement pour qu'il ait « le même effet intuitif ». Ils font le même amalgame que moi (mais avec rigueur).
C'est pas ça qui t'a induit en erreur ?
N'hésite pas à poser des questions si tu trouves des imprécisions, les commentaires sont justement là pour discuter des détails intéressants.
Je tiens tout de même à rappeler que la dépêche n'est pas normative et, elle n'a pas la rigueur d'une RFC ni d'une doc, ni d'un papier de recherche. Tu va pouvoir trouver une quantité phénoménale d'imprécisions dedans.
[^] # Re: Java, flash
Posté par raphj (site web personnel) . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 7. Dernière modification le 19 avril 2021 à 13:58.
D'accord, mais tu n'étais pas obligé de transmettre du XML avec. Tu pouvais transmettre des données plain text, des scripts javascript... bref, l'objet n'a rien de spécifique à XML et en programmation on a quand même pas mal l'habitude de séparer les probèmes...
Ce n'est vraiment pas moi qui le dit, pour le coup, je n'ai rien inventé c'est la personne qui a conçu XmlHttpRequest (premier lien de la dépêche) !
C'est décrit dans la dépêche... qui reste une dépêche, pas une doc.
Je ne sais pas précisément ce que tu entends par là mais sur cette page : https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
Donc si tu dis que fetch est utilisable dans un worker, ce n'est pas un contre exemple d'un truc que fetch peut faire et pas XMLHttpRequest
Je ne doute pas que dans le futur, les APIs vont continuer à évoluer et je ne serais pas étonné si fetch finissait par faire des choses que XmlHttpRequest ne fait pas.
À noter que le mécanisme de keep-alive ne remonte pas jusqu'au code utilisant l'objet WebSocket (ce qui ne contredit en rien ton affirmation, on est tout à fait d'accord).
Pour le contexte :
Tu as raison, j'ai utilisé le mot « connexion » un peu négligemment mais ça ne change pas le sens de ce passage ni le raisonnement autour.
Le passage de la doc de Nginx n'a rien de surprenant : il avertit simplement que le paramètre dont il est question n'a pas exactement le même sens en HTTP 1.1 qu'en HTTP 2, justement pour qu'il ait « le même effet intuitif ». Ils font le même amalgame que moi (mais avec rigueur).
N'hésite pas à poser des questions si tu trouves des imprécisions, les commentaires sont justement là pour discuter des détails intéressants.
Je tiens tout de même à rappeler que la dépêche n'est pas normative et, elle n'a pas la rigueur d'une RFC ni d'une doc, ni d'un papier de recherche. Tu va pouvoir trouver une quantité phénoménale d'imprécisions dedans.