Блог

В контексте beforeunload обработчика, в чем функциональная разница между fetch(keep-alive: true) и установкой src атрибута img тега, и какой из них является предпочтительным методом для выполнения запросов GET?

Предыстория:

Я хочу отправить HTTP GET-запрос в beforeunload обработчике в коде JavaScript. Navigator.sendBeacon в документации обсуждается, насколько он хорош для данного варианта использования, но

Метод sendBeacon () не предоставляет возможности настраивать метод запроса

По-видимому, несколько лет назад было много запросов на подобную функциональность, кульминацией которых стала рекомендация использовать fetch() метод браузера, вызываемый внутри sendBeacon , с некоторыми определенными флагами, установленными для решения unload проблемы запроса:

Приложения, которым требуются настройки не по умолчанию для таких запросов, должны использовать FETCH API с флагом keep-alive, установленным в true

 fetch(url, {
  method: ..., 
  body: ...,            
  headers: ...,       
  credentials: 'include',
  mode: 'cors',
  keep-alive: true,
})
  

Насколько я могу судить, этот тип вызова был бы функционально эквивалентен Navigator.sendBeacon , поскольку настройка ключа является keep-alive: true .

По-видимому, <img> тег HTML также используется keep-alive: true в соответствии со спецификацией (курсив мой):

С запросом связан флаг keepalive…Это может быть использовано, чтобы разрешить запросу пережить объект настроек среды, например, navigator.sendBeacon и элемент HTML img устанавливают этот флаг

Я понимаю эту документацию так, что выполнение GET запроса на unload через img атрибут src fetch() элемента функционально эквивалентно вызову keep-alive: true с помощью, что само sendBeacon по себе функционально эквивалентно вызову sendBeacon (если GET можно было бы делать в этом случае запросы).

Это точно?

Согласно https://fetch.spec.whatwg.org/#request-class это keepalive , не keep-alive .

Кроме этого, да. Эта функция была добавлена, чтобы fetch() отпала необходимость в sendBeacon() .