Server push

Le HTTP server push (parfois nommé HTTP streaming) est le nom donné à la technique push appliquée au protocole HTTP. Plusieurs méthodes permettent d'aboutir à un push serveur, la plus commune étant d'empêcher le serveur de clore la transaction. La connexion client-serveur reste ainsi ouverte, ce qui permet de mettre à jour instantanément les données chez les clients liés et évite de créer des queues parfois coûteuses du côté serveur. Cette fonctionnalité est disponible sur le serveur Apache via CGI.

Une autre possibilité pour réaliser le push est d'utiliser l'en-tête Mime multipart/x-mixed-replace, mis en place par le navigateur Netscape Navigator en 1995[1] - [2]. Bien que la plupart des navigateurs récents soient à même d'exploiter cet en-tête, Microsoft n'envisage toujours pas de doter son navigateur de cette technique[3].

Le WHATWG travaille actuellement à la standardisation de cette technique : le Server Sent Event[4] implémentée par l'essentiel des navigateurs récents[5] À la différence du modèle créé par Netscape, le server sent event est basé sur la création du nouveau type Mime text/event-stream, dont les données seront directement exploitables à travers l'arbre DOM.

Le Java pushlet (mot-valise créé à partir de push et applet) est une technique développée pour les applications web en Java, bien qu'elle soit maintenant utilisée dans d'autres frameworks. Ici, le serveur exploite l'utilisation de connexions persistantes (voir aussi l'article sur HTTP 1.1). Comme pour les autres méthodes, le serveur ne clôt pas le dialogue avec son client, et berne ce dernier, le laissant en mode de chargement et lui envoyant régulièrement de petites instructions en JavaScript afin de rafraîchir la page. L'intérêt de cette méthode réside dans le fait que le client n'a besoin ni d'applet, ni de plugin pour garder sa connexion ouverte[6] - [7]. Toutefois, cette méthode souffre d'un sérieux inconvénient qui se situe au niveau du timeout autorisé par le navigateur, qui implique un rafraîchissement manuel de la page.

Le long polling est une variation de la technique de polling et permet d'émuler le mécanisme de push dans certaines circonstances où le push n'est pas possible comme pour les sites avec des règles de sécurité qui requièrent le rejet des requêtes HTTP/S entrantes.

Avec le long polling, le client demande des informations au serveur exactement comme dans le fonctionnement « classique » mais en s'attendant à ce que le serveur ne réponde pas immédiatement. Si le serveur n'a pas de nouvelles informations pour le client à la réception de la requête, au lieu de renvoyer une réponse vide, il garde la requête ouverte et attend que l'information demandée soit disponible. Une fois qu'il a de nouvelles informations, le serveur envoie immédiatement une réponse HTTP/S au client, terminant ainsi la requête HTTP/S. Généralement, à la réception de la réponse du serveur, le client lance immédiatement une nouvelle requête. De cette manière, la latence (le temps entre le moment où l'information devient disponible et la prochaine requête client) qui est présente avec les techniques de polling classiques est éliminée[8].

Par exemple, BOSH est une technique HTTP populaire fondée sur le principe du long polling qui est utilisée comme une alternative aux connexions TCP continues lorsque ce type de connexion est difficile voire impossible à employer directement (dans les navigateurs web par exemple)[9]; c'est aussi une technologie sous-jacente pour le XMPP utilisé par Apple pour gérer le push dans iCloud.