Зачем вообще загружать данные размером 1x1 пиксель GIF (веб-ошибки)?

Многие аналитические и отслеживающие инструменты запрашивают изображение 1x1 GIF (веб-ошибка, невидимая для пользователя) для хранения/обработки событий между доменами.

Зачем вообще использовать этот образ GIF? Не было бы более эффективным просто вернуть некоторый код ошибки, например 503 Service Temporary Unavailable или empty file?

Обновление. Чтобы быть более ясным, я спрашиваю, почему использовать данные изображения GIF, когда все запрашиваемые данные уже отправлены в заголовках запроса. Сам образ GIF не возвращает никакой полезной информации.

Ответ 1

Ответ Дуга довольно всеобъемлющий; Я думал, что добавлю дополнительную заметку (в запросе OP, вне моего комментария)

Ответ Doug объясняет, почему 1x1 пиксельные маяки используются для цели, для которой они используются; Я думал, что я опишу потенциальный альтернативный подход, который должен использовать HTTP-код состояния 204, No Content, для ответа и не отправлять тело изображения.

204 Нет содержимого

Сервер выполнил запрос но не нужно возвращать сущность-тело, и, возможно, захочет вернуться обновленная метаинформация. Ответ МОЖЕТ включать новые или обновленные метаинформация в виде сущности-заголовки, которые, если они присутствуют СЛЕДУЕТ связываться с запрошенный вариант.

В принципе, сервер получает запрос и решает не отправлять тело (в этом случае, чтобы не отправлять изображение). Но он отвечает кодом, чтобы сообщить агенту, что это было сознательное решение; в основном, его просто более короткий способ ответить утвердительно.

От Документация по скорости страницы Google:

Один популярный способ записи страницы взглядов в асинхронном режиме включить фрагмент кода JavaScript в нижней части целевой страницы (или как onload), который уведомляет сервер регистрации, когда пользователь загружает стр. Самый распространенный способ это построить запрос к сервер для "маяка" и кодировать все данные, представляющие интерес, в качестве параметров в URL-адрес ресурса маяка. к чтобы HTTP-ответ был очень мал, прозрачное изображение размером 1x1 пиксель является хорошим кандидата на запрос маяка. немного более оптимальный маяк будет использовать ответ HTTP 204 ( "без содержимого" ) который немного меньше, чем 1x1 GIF.

Я никогда не пробовал, но теоретически он должен работать с той же целью, не требуя передачи самого gif, сэкономив вам 35 байт, в случае с Google Analytics. (В схеме вещей, если вы не являетесь Google Analytics, обслуживающим множество триллионов обращений в день, 35 байт на самом деле ничего.)

Вы можете протестировать его с помощью этого кода:

var i = new Image(); 
i.src = "http://httpstat.us/204";

Ответ 2

Во-первых, я не согласен с двумя предыдущими ответами - не затрагивает вопрос.

Однопиксельное изображение решает внутреннюю проблему для веб-аналитических приложений (например, Google Analytics) при работе в HTTP-протоколе - как передавать (веб-метрики) данные от клиента на сервер.

Самый простой из методов, описанных в Протоколе, самый простой (по крайней мере, самый простой метод, включающий тело запроса) - это запрос GET. В соответствии с этим методом протокола клиенты инициируют запросы к серверам для ресурсов; серверы обрабатывают эти запросы и возвращают соответствующие ответы.

Для веб-аналитического приложения, такого как GA, эта однонаправленная схема - плохая новость, потому что она не позволяет серверу получать данные от клиента по требованию - опять же, все серверы могут делать это ресурсы ресурсов не запрашивают их.

Итак, какое решение проблемы с возвратом данных с клиента на сервер? В контексте HTTP существуют другие методы протокола, отличные от GET (например, POST), но ограниченный вариант по многим причинам (о чем свидетельствует его редкое и специализированное использование, например, представление данных формы).

Если вы посмотрите на запрос GET в браузере, вы увидите, что он состоит из URL-адреса запроса и заголовков запросов (например, заголовков Referer и User-Agent), последний содержит информацию о клиенте - например, тип и версия браузера, langauge браузера, операционная система и т.д.

Опять же, это часть запроса, который клиент отправляет на сервер. Таким образом, идея, которая мотивирует однопиксельный gif, заключается в том, что клиент отправляет данные веб-метрики на сервер, завернутые внутри заголовка запроса.

Но тогда как заставить клиента запрашивать ресурс, чтобы его можно было "обмануть" в отправке данных метрик? И как заставить клиента отправлять фактические данные, которые хочет сервер?

Хорошим примером является Google Analytics: файл ga.js(большой файл, загрузка которого клиентом запускается небольшим script на веб-странице), включает несколько строк кода, которые направляют клиента на запрос конкретный ресурс с определенного сервера (сервер GA) и отправить определенные данные, завернутые в заголовок запроса.

Но так как цель этого Запроса состоит не в том, чтобы фактически получить ресурс, а для отправки данных на сервер, этот ресурс должен быть как можно меньшим, и он не должен быть видимым при визуализации на веб-странице - следовательно, 1 x 1 пиксель прозрачный gif. Размер минимально возможный, а формат (gif) - самый маленький среди форматов изображений.

Точнее, все данные GA - каждый отдельный элемент - собраны и упакованы в строку запроса запроса URL запроса (все после "?" ). Но для того, чтобы эти данные переходили от клиента (где он был создан) к серверу GA (где он регистрируется и агрегируется), должен быть HTTP-запрос, поэтому ga.js(google analytics script, который загружен, если он не кэшируется клиентом в результате функции, вызываемой при загрузке страницы) направляет клиента на сбор всех данных аналитики - например, куки, панель местоположений, заголовки запросов и т.д. - объединяет их в одну строку и добавить ее как строку запроса в URL ( * http://www.google-analytics.com/__utm.gif*?), и это станет URL-адресом запроса.

Легко это доказать с помощью любого веб-браузера, который позволяет вам просматривать HTTP-запрос для веб-страницы, отображаемой в вашем браузере (например, Safari Web Inspector, Firefox/Chrome Firebug и т.д.).

Например, я напечатал действительный url на домашней странице корпорации в моей строке местоположения браузера, которая вернула эту домашнюю страницу и отобразила ее в моем браузере (я мог выбрать любой веб-сайт/страницу, которая использует одну из основных аналитических возможностей приложения, GA, Omniture, Coremetrics и т.д.)

В браузере, который я использовал, был Safari, поэтому я нажал кнопку "Развернуть" в строке меню, а затем "Показать веб-инспектор". В верхней строке веб-инспектора выберите "Ресурсы", найдите и щелкните ресурс utm.gif из списка ресурсов, указанных в левом столбце, затем перейдите на вкладку "Заголовки". Это покажет вам что-то вроде этого:

Request URL:http://www.google-analytics.com/__utm.gif?
           utmwv=1&utmn=1520570865&
           utmcs=UTF-8&
           utmsr=1280x800&
           utmsc=24-bit&
           utmul=enus&
           utmje=1&
           utmfl=10.3%20r181&

Request Method:GET
Status Code:200 OK

Request Headers
    User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1 
                 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Response Headers
    Cache-Control:private, no-cache, no-cache=Set-Cookie, proxy-revalidate
    Content-Length:35
    Content-Type:image/gif
    Date:Wed, 06 Jul 2011 21:31:28 GMT

Ключевыми моментами для уведомления являются:

Запрос был фактически запросом для utm.gif, о чем свидетельствует первая строка выше: * Запрос URL: HTTP:.//www.google-analytics.com/__utm.gif*
Параметры Google Analytics хорошо видны в строке запроса добавляется к URL-адресу запроса: например, utmsr - имя переменной GA для обращения к экрану клиента разрешение, для меня, показывает значение 1280x800; utmfl - переменная имя для флеш-версии, которая имеет значение 10.3 и т.д.
Заголовок ответа называется Content-Type (отправляется сервером обратно клиенту) также подтверждает что запрашиваемый ресурс и return был размером 1x1 пиксель gif: Content-Type: изображение /GIF

Эта общая схема передачи данных между клиентом и сервером существует навсегда; вполне может быть лучший способ сделать это, но это единственный способ, которым я знаю (который удовлетворяет ограничениям, налагаемым размещенной службой аналитики).

Ответ 3

Некоторые браузеры могут отображать значок ошибки, если ресурс не мог загрузить. Это делает отладку/мониторинг службы еще более сложной, вы должны убедиться, что ваши средства мониторинга обрабатывают ошибку как хороший результат.

OTOH вы ничего не получаете. Сообщение об ошибке, возвращаемое сервером/фреймворком, обычно больше, чем изображение 1x1. Это означает, что вы увеличиваете сетевой трафик, в основном ничего.

Ответ 4

Поскольку такой GIF имеет известную презентацию в браузере - это один пиксель, период. Все остальное представляет риск визуального вмешательства в фактическое содержание страницы.

Ошибки HTTP могут отображаться как негабаритные кадры текста ошибки или даже как всплывающее окно. Некоторые браузеры также могут жаловаться, если они получают пустые ответы.

Кроме того, изображения на странице являются одним из немногих типов данных, разрешенных по умолчанию во всех браузерах. Все, что может потребоваться, требует явного пользовательского действия для загрузки.

Ответ 5

Это ответ на вопрос OP - "зачем обслуживать данные изображения GIF..."

Некоторые пользователи помещают простой тег img для вызова службы регистрации событий -

<img src="http://www.example.com/logger?event_id=1234">

В этом случае, если вы не показываете изображение, браузер отобразит значок замещающего, который будет выглядеть уродливым и создаст впечатление, что ваша служба нарушена!

Что я делаю, найдите поле заголовка Принять. Когда ваш script вызывается с помощью тега img, как это, вы увидите что-то вроде следующего в заголовке запроса -

Accept: image/gif, image/*
Accept-Encoding:gzip,deflate
...

Когда в поле заголовка Принять есть строка "image/" *, я поставлю изображение, иначе я просто ответю на 204.

Ответ 6

Ну, основная причина заключается в том, чтобы прикрепить к нему файл cookie, поэтому, если пользователи переходят с одной стороны на другую, мы все равно имеем один и тот же элемент для присоединения файла cookie.

Ответ 7

Вам не нужно обслуживать изображение, если вы используете метод реализации Beacon API (https://w3c.github.io/beacon/).

Код ошибки будет работать, если у вас есть доступ к файлам журналов вашего сервера. Цель обслуживания изображения - получить больше данных о пользователе, чем вы обычно делаете с файлом журнала.

Ответ 8

@Maciej Perliński в основном правильно, но я чувствую, что подробный ответ будет полезным.

почему 1x1 GIF, а не код состояния 204 No-Content?

204 No-Content позволяет серверу опускать все заголовки ответа (Content-Type, Content-Length, Content-Encoding, Cache-Control и т.д.) И возвращать пустое тело ответа с 0 байтами (и сохраняя много ненужной пропускной способности),

Браузеры знают, что нужно уважать ответы 204 No-Content, а не ожидать/ждать заголовков ответа и тела ответа.

если серверу необходимо установить какой-либо заголовок ответа (например, cache-control или cookie), он не может использовать 204 No-Content, поскольку браузеры будут игнорировать любой заголовок ответа по своему замыслу (согласно спецификации протокола HTTP).

почему 1x1 GIF, а не заголовок Content-Length: 0 с кодом статуса 200 OK?

Вероятно, сочетание нескольких вопросов, просто назвать несколько:

совместимость с устаревшими браузерами
MIME-тип проверяет в браузерах, 0 байтов не является допустимым изображением.
200 OK с 0 байтами может не полностью поддерживаться промежуточными прокси-серверами и VPN