También disponible en: English · Português · Français · العربية
Server-sent events: analiza el flujo y mira qué se dispara
Pega un flujo de eventos y obtén los que se despachan, el último ID en cada uno y el motivo por el que las demás líneas no hicieron nada.
¿Qué son los server-sent events?
Los server-sent events son la mitad sencilla del tiempo real en la web: el servidor mantiene abierta una respuesta y va escribiendo líneas de texto, el navegador convierte cada bloque de líneas en un evento y tu código escucha. Sin apretón de manos, sin tramas, sin biblioteca: una respuesta con el tipo de contenido text/event-stream y un cuerpo de líneas como data: algo. Es lo que usan casi todas las APIs de streaming para ir empujando tokens según se generan, y es un formato lo bastante simple como para que la gente escriba servidores a mano.
Y escribirlo a mano es justo donde empiezan los problemas, porque el formato es más estricto de lo que aparenta. El algoritmo de análisis está especificado por completo, hasta qué búfer guarda qué y cuándo se vacía cada uno, y varias de sus reglas son lo contrario de lo que sugiere la forma de la sintaxis. Un flujo puede parecer del todo razonable, no contener ningún error y no entregar nada.
Esta página ejecuta ese algoritmo sobre lo que pegues. Muestra los eventos que salen, con el último ID tal como lo tendría el analizador en ese momento, y muestra cada línea que no aportó nada junto con el motivo. Esa segunda mitad suele ser la que venías a buscar.
Cómo usarlo
- Pega el cuerpo del flujo. El cuerpo de la respuesta tal como viajó, no las cabeceras. Las líneas pueden terminar en salto de línea, en retorno de carro o en ambos: los tres valen, y entre los ejemplos hay un flujo que usa cada uno.
- Lee los eventos que se dispararon. Cada uno con su tipo, sus datos y el último ID en el momento del despacho. Si la tabla sale vacía, el bloque de abajo explica qué línea tuvo la culpa.
- Mira las líneas que no hicieron nada. Comentarios, campos desconocidos, un nombre de campo con las mayúsculas cambiadas, un id con un carácter nulo, un retry que no es un número, y cualquier bloque que terminó sin despachar. Cada fila dice cuál de esos casos era.
La regla con la que tropieza todo el mundo
Un evento sin datos no se despacha. La especificación es explícita: si al llegar una línea en blanco el búfer de datos está vacío, el analizador vacía los búferes y vuelve sin producir nada. Así que un servidor que envía un campo event y una línea en blanco —una forma perfectamente natural de escribir un latido— no dispara ningún oyente, no registra ningún error y no muestra nada en el panel de red salvo un flujo que parece estar funcionando.
La solución es un campo data, aunque venga vacío, o un comentario. Un data vacío basta, porque el analizador añade un salto de línea al búfer por cada línea data, así que el búfer deja de estar vacío aunque el valor lo esté. Una línea de comentario son dos puntos seguidos de lo que sea, y es la manera convencional de mantener viva una conexión: no reinicia el temporizador de nadie y no produce nada.
La otra mitad de la misma regla es fácil de pasar por alto en sentido contrario. El búfer del tipo de evento se vacía en cada despacho, así que un evento sin campo event es un message. El del último ID no: la especificación dice con todas las letras que no se reinicia, de modo que conserva su valor hasta que el servidor lo vuelva a fijar. Dos búferes, uno al lado del otro en el mismo algoritmo, con vidas opuestas. Un evento sin id hereda el anterior, y eso es lo que se manda de vuelta en la cabecera Last-Event-ID cuando la conexión se cae y el navegador reconecta.
Cuatro reglas menores que conviene saber
Se quita exactamente un espacio inicial del valor. Uno. La línea data: hola y la línea data:hola significan lo mismo, pero data: hola con dos espacios conserva uno. Es una forma habitual de colar un espacio de más dentro de un JSON que luego no parsea sin motivo aparente.
Los nombres de campo se comparan tal cual, sin plegado de mayúsculas. Data no es data. Un nombre con mayúscula no es un error y no se avisa en ninguna parte: sencillamente es un campo desconocido, y los campos desconocidos se ignoran. Lo mismo vale para cualquier errata: hay exactamente cuatro nombres de campo y todo lo demás se descarta en silencio.
Un id cuyo valor lleve un carácter nulo se ignora entero. Ni se corta en el nulo ni se vacía: el búfer conserva lo que tuviera, así que el siguiente evento hereda el id anterior. Y un retry solo se aplica si su valor está hecho únicamente de dígitos, lo que deja fuera un número negativo, un decimal y cualquier cosa con una unidad pegada.
Por último, un flujo que se corta a mitad de evento pierde ese evento. La especificación dice que al llegar al final hay que descartar cualquier dato pendiente, así que un bloque con una línea data pero sin línea en blanco detrás no llega nunca. Esta herramienta distingue ese caso del de un flujo que se corta a mitad de línea, donde los últimos caracteres nunca llegaron a ser una línea y ni siquiera se miraron.
Lo que esta herramienta no hace
No se conecta a nada. Tú pegas un cuerpo; la página lo lee. Para capturar un flujo real, el panel de red de tu navegador muestra la respuesta según llega, y un cliente HTTP de línea de órdenes la imprime conforme va cayendo.
Lee un flujo completo y no uno en vivo, y eso hace que un caso se comporte distinto que en un cliente real. Un flujo que acaba en un retorno de carro suelto aquí no tiene ambigüedad, porque detrás no hay nada; un analizador en streaming que reciba esos mismos bytes tiene que retener ese retorno de carro por si el siguiente trozo empieza por un salto de línea, ya que los dos juntos son un único final de línea. Ambos comportamientos son correctos para lo que cada uno es.
Tampoco comprueba que tus datos sean JSON válido, ni ninguna otra cosa. El formato transporta texto y no se interesa por lo que ese texto significa, lo cual conviene recordar: un campo data repartido en varias líneas se vuelve a unir con saltos de línea entre los trozos, y esa es una forma legal de enviar un JSON con formato que muchos servidores escritos a mano producen sin querer.
¿Por qué es gratis?
Leer líneas de una cadena es algo que tu navegador hace al instante. No hay servidor de por medio, así que no hay nada que facturar ni cuenta que crear.
No se sube nada. El flujo que pegas se queda en esta pestaña.