Reverse HTTP (2)

Una de las novedosas técnicas que están apareciendo para resolver el problema de la asimetría de HTTP (que el servidor web notifique a los navegadores sobre nuevas actualizaciones como los mensajes de un chat) pasa por aprovechar la tecnología Comet (una conexión persistente entre navegador y servidor que permite que el servidor le envie datos al navegador en cuanto los tenga disponibles y sin que el navegador los haya solicitado explícitamente).

La idea es que el navegador abre una conexión persistente con el servidor, el cual le asigna una URL (generalmente un subdominio) propia cuyas peticiones son respondidas por el Javascript residente en la página del navegador. De esa forma, la página estática mostrada en el navegador se convierte a todos los efectos en un servidor web capaz de responder a las peticiones entrantes como un servidor web tradicional.

Traduzco la página reversehttp.net donde se explica con más detalle el funcionamiento de esta técnica.

Realizar solicitudes para averiguar si hay actualizaciones es malo. Sabemos esto desde que existen los ordenadores. Pero si es así, ¿por qué hay tantos servicios basados en web (SUP, fuentes RSS y Atom, Twitter, etc.) basados en esas solicitudes?

La respuesta está, en primer lugar, en la asimetría de HTTP. La web está dividida en dos piezas: programas que realizan peticiones y programas que las manejan. Es muy raro ver un mismo programa comportándose a la vez como cliente y como servidor.

Para arreglar esta asimetría necesitamos ser capaces de actuar como si poder responder a las peticiones HTTP fuese fácil para los programas, de forma que podamos notificar los cambios a las partes interesadas simplemente enviándoles una petición HTTP. Esta es la idea principal de los web hooks.

Necesitamos hacer fuerza para empujar los procesos que traten con long-polling (Comet) lejos del núcleo de la web y hacia sus límites que es donde tiene que estar.

Necesitamos hacer que los programas pidan dinámicamente un pedazo del espacio de URLs usando un viejo cliente HTTP y gestionar las peticiones enviadas a las URLs en ese espacio usando ese mismo cliente HTTP.

Una vez que eso esté hecho, la notificación asíncrona de eventos estará al alcance de cualquier programa que tenga acceso a una librería cliente de HTTP, y los protocolos y servicios sobre HTTP no tendrán que contorsionarse para tratar con la asimetríá de HTTP. Pueden suponer que todo el mundo es un servidor y solicitar y enviar contenidos desde y hacia donde quieran.

La solución

Crear un túnel HTTP sobre HTTP de una forma estructurada, controlable y segura. Deja que los programas pidan una parte del espacio de URLs y sirve HTTP, todo por medio de una librería ordinaria cliente de HTTP.

• Lee el borrador de la especifición.
• Comprueba implementación.
• Prueba las demos.

Incluso los programas que se ejecutan en entornos muy restrictivos, como Javascript en el navegador, pueden sacar ventaja del servicio ReverseHTTP. La implementación actual provee librerías sencillas y pequeñas para Python, Java y para el Javascript del navegador.

¿Por qué no se ha hecho esto antes?

Esta no es una idea completamente nueva, como parece, aunque no parece haberse usado ampliamente hasta el momento.

Prácticamente al mismo tiempo que estaba escribiendo ReverseHttp (hacia Mayo de 2008), Donovan Preston de Second Life escribía su versión de la misma idea, que también llamó Reverse HTTP (también conocida como "PTTH"). Su idea es usar la cabecera Upgrade de HTTP 1.1 para intercambiar la dirección del protocolo, lo que funciona bien para entornos distintos del navegador. Él también tiene una solución basada en Comet muy similar a la mía, excepto que la suya usa objetos JSON para describir las peticiones y respuestas HTTP mientras la mia usa los formatos de los mensajes HTTP. Donovan Preston escribe más sobre la variante Second Life aquí, y ha producido, junto a Mark Lentczner, un borrador (Internet-Draft) para el protocolo basado en la cabecera Upgrade.

Descargas y enlaces

• Instrucciones para descargar la implementación
• Hay varios artículos sobre esta técnica en otros sitios:
  • http://www.eflorenzano.com/blog/post/reverse-http/
  • http://ulaluma.com/pyx/archives/2008/12/ptth_reverse_ht.html
  • http://t0rxon.blogspot.com/2009/02/making-real-time-web-real-time.html
  • http://kirkwylie.blogspot.com/2008/12/scoble-joins-real-time-web-conversation.html
  • http://kirkwylie.blogspot.com/2008/12/rest-requires-asynchronous-notification.html
  • http://www.webhooks.org/
  • http://news.ycombinator.com/item?id=508238

---

Addendum

Es posible comprender mejor la potencia de esta técnica con la demo online disponible en http://www.reversehttp.net/demos/demo.html