Summary

  • Первый рабочий проект W3C по Server-Sent Events от 23 апреля 2009 года описал EventSource: страница принимает события от сервера по продолжающемуся HTTP-соединению.
  • Событие могло содержать поле id. После обычного разрыва браузер передавал сохранённый номер в Last-Event-ID; пустое поле id стирало эту отметку.

Табло с котировками замерло. Можно на мгновение вообразить, что биржа вдруг взяла выходной ради душевного равновесия. Потом на экране появляется новое число — и становится тревожнее. Что было между старым и новым? Возвращение связи само по себе не сообщает, сколько сообщений проскочило за время тишины.

Рабочий проект W3C от 23 апреля 2009 года предложил EventSource. Страница открывает адрес и ждёт сообщения, сервер отвечает потоком с типом text/event-stream. Браузер читает строки, собирает их в законченные события и отдаёт обработчику страницы. Соединение может оставаться открытым, а сообщения — иметь понятные границы. Для следующего соединения понадобилась ещё и отметка о том, до какой границы клиент дошёл.

Пример с акциями в документе выглядит как кусочек ленты: три строки data со значениями YHOO, +2 и 10. Пустая строка завершает блок. Браузер передаёт одно событие с тремя строками данных; скрипт разделяет их и обновляет табло. Пустая строка играет роль точки в потоке, который собирается говорить ещё долго.

В другом примере к сообщению data: first event добавлено id: 1. Браузер запоминает единицу. Если связь обрывается до следующего события, в новом запросе появляется Last-Event-ID: 1. Декабрьский проект 2009 года на этапе последнего сбора замечаний сохранил этот порядок. Клиент возвращается с закладкой, а не с просьбой восстановить «то, что было сразу после какой-то новости».

Закладка имеет смысл, когда сервер может с ней работать. Если прежние события сохранены, он подберёт продолжение. Если старые записи удалены или началась новая торговая сессия, ему придётся выбрать другое поведение. Срок хранения, способ возобновления и обращение с устаревшим номером принадлежат службе рассылки. Браузер точно знает, что он уже получил. Сервер знает, что осталось в архиве. Небольшое поле заголовка даёт им возможность сверить эти знания.

Авторы проекта предусмотрели и момент, когда закладку пора выбросить. В следующем блоке примера поле id оставлено без значения. Сохранённый номер становится пустым; при очередном подключении заголовок Last-Event-ID уже не отправляется. Вчерашняя страница биржевого журнала перестаёт диктовать, где начинать сегодняшнюю. Право обнулить отсчёт оказывается частью того же механизма, что и право его продолжить.

Строка, начинающаяся с двоеточия, служит комментарием и не превращается в событие на странице. Рекомендация W3C от февраля 2015 года советовала время от времени посылать такую строку, чтобы некоторые старые прокси не закрывали слишком долго молчащее соединение. Там же описаны retry, управляющий ожиданием перед новой попыткой, и ответ HTTP 204 No Content, после которого клиент прекращает попытки. Даже ленте новостей полезно уметь подать знак жизни и объявить, что смена закончилась.

История публикаций W3C показывает путь от проектов 2009 года через снимок кандидатской рекомендации 2012-го к рекомендации 2015-го. Суть сохранилась: простой текстовый поток, номер события, новый запрос с последней увиденной позицией. Из этой скромной конструкции выросла возможность обсуждать разрыв связи на языке конкретных событий, а не на языке неопределённого «кажется, что-то пропало».

Недавняя история Web Workers касается другой границы. Рабочий скрипт берёт на себя долгий расчёт, чтобы страница могла отвечать на нажатия. EventSource принимает сообщения с сервера и после обрыва возвращает туда номер последнего принятого. В одном случае распределена работа, в другом — память о последовательности. У биржевой ленты есть право на паузу. У читателя есть право знать, откуда она продолжилась.