Summary

  • El borrador de trabajo de W3C del 23 de abril de 2009 presentó EventSource, una conexión HTTP desde la que una página recibe eventos enviados por el servidor.
  • Cada evento podía llevar un campo id. Si la línea se interrumpía, el navegador incluía la última posición recordada en Last-Event-ID; un id vacío borraba esa posición.

El marcador bursátil deja de moverse justo cuando uno empieza a mirarlo. Tal vez el mercado ha decidido descansar. Tal vez el cable ha hecho lo que suelen hacer los cables en el peor momento. Cuando vuelve la señal, el número nuevo parece convincente, pero queda una duda bajo la mesa: ¿cuántas noticias han pasado mientras la pantalla estaba callada?

El primer borrador de Server-Sent Events, publicado por W3C el 23 de abril de 2009, abordó esa conversación interrumpida con EventSource. La página abre una dirección y escucha. El servidor responde con un flujo text/event-stream. El navegador agrupa las líneas recibidas y entrega eventos al programa de la página. El formato no pedía una ceremonia complicada: datos, líneas vacías y, cuando hacía falta, una etiqueta para saber cuál había sido el último mensaje.

La demostración del documento parecía un recorte de una cinta de cotizaciones. Tres líneas data contenían YHOO, +2 y 10. La línea vacía que venía después cerraba el bloque. El navegador emitía un solo evento con tres líneas de contenido; el código de la página las separaba y actualizaba la cotización. Esa estructura explicaba la primera mitad del problema: cómo reconocer un mensaje completo dentro de una respuesta HTTP que seguía abierta.

La otra mitad empezaba con id: 1. El ejemplo daba ese identificador al primer evento. Si la conexión desaparecía antes del siguiente, el navegador regresaba con Last-Event-ID: 1 en su nueva petición. El borrador de última convocatoria de diciembre de 2009 conservó el mecanismo. La página llevaba un marcapáginas. Ya no entraba en el archivo del servidor diciendo «creo que me perdí por algún sitio de la página tres».

El marcapáginas servía para que el servidor tomara una decisión informada. Si guardaba un historial, podía usar el identificador para elegir el siguiente evento. También podía haber limitado el historial, cambiado de sesión o decidido comenzar una secuencia nueva. La continuidad dependía de lo que el servicio había conservado. El protocolo ponía sobre la mesa la posición del lector; la memoria de las noticias vivía al otro lado de la mesa.

El propio borrador mostraba cómo retirar un marcapáginas caducado. Un bloque posterior incluía un campo id sin valor. Eso vaciaba el identificador recordado: en una reconexión futura ya no habría Last-Event-ID que enviar. Es un detalle pequeño con buen instinto editorial. Una cinta nueva merece un punto de partida nuevo. Arrastrar para siempre un número de una sesión anterior solo haría que ambas partes discutieran sobre una página que ya no existe.

También había líneas que no anunciaban nada al usuario. Una línea que empieza por dos puntos es un comentario y no produce un evento visible. La Recomendación de W3C de febrero de 2015 observó que esos comentarios podían enviarse de vez en cuando para mantener vivas conexiones que ciertos intermediarios antiguos cerraban tras un rato de silencio. La misma especificación describió retry para ajustar la espera antes de volver a llamar y la respuesta HTTP 204 No Content para indicar que ya no debía insistirse. Hasta un sistema de noticias en directo necesita saber cuándo respirar y cuándo colgar.

El historial oficial de publicación coloca el diseño en su secuencia: borradores de 2009, una instantánea de recomendación candidata en 2012 y Recomendación en 2015. El mérito del intercambio estaba en su economía. El navegador no tenía que conservar toda la cinta. El servidor no tenía que adivinar cuál fue la última línea que llegó a la pantalla. Compartían un número y continuaban la conversación con la información que cada uno sí tenía.

El asunto se distingue de Web Workers, aunque en los dos haya mensajes. Un worker aparta un cálculo pesado de la parte de la página que atiende los clics. EventSource trae una secuencia desde un servidor y ayuda a negociar dónde reanudarla tras el corte. En un caso se reparte el trabajo; en el otro se reparte la memoria de una conversación. El botón agradece el primero. El teletipo, el segundo.