Эквивалент 404 для веб-сокета

Question

Я использую веб-сокеты для передачи информации о ресурсе с сервера клиенту. Конечная точка websocket использует pathparam для идентификации конкретного ресурса. Например:

@ServerEndpoint("/resources/{resource-id}/updates")

Класс Endpoint имеет следующую логику в своем onOpen метод:

@OnOpen
public void onOpen(@PathParam("resource-id")int resourceId, Session session) throws IOException {
     boolean resourceExists = checkIfResourceExists(resourceId);
     if (!resourceExists) {
         // what should I do here?
     }
}

При использовании длинного опроса AJAX я отправляю ответ 404, если ресурс не существует. Тогда клиент знал бы, что не стоит пытаться снова. Есть ли эквивалентный метод для использования с веб-сокетами? Мои две мысли:

1. Используйте следующий код в if (!resourceExists) блок, выше:

   session.close(new CloseReason(CUSTOM_NOT_FOUND_CODE, "Resource ID not found")); return;

   куда CUSTOM_NOT_FOUND_CODE является CloseCode в диапазоне 4000-4999.

2. Выполните эту логику где-то в ServerEndpointConfig.Configurator реализации для этой конечной точки и вернуть 404 до обновления соединения. Это звучит как лучший подход для меня, но, кажется, нет никакого способа отправить стандартный ответ об ошибке HTTP от modifyHandshake метод.

3. Выполните эту логику в фильтре. Однако проблема здесь в том, что если я загружаю ресурс в фильтр, как мне передать его в конечную точку? С помощью HTTP-запроса я могу добавить атрибут запроса в фильтр, который затем будет доступен в сервлете. Но, кажется, нет простого способа добиться того же с помощью веб-сокетов. Конечно, я мог бы снова загрузить ресурс в класс Endpoint, но это дублирование работы.

Я уверен, что это должен быть распространенный сценарий, так что здесь принят приемлемый подход?