Навіщо взагалі обслуговувати дані GIF розміром 1х1 піксель (веб-помилки)?


81

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

Навіщо взагалі подавати цей GIF-образ? Чи не було б ефективніше просто повернути якийсь код помилки, наприклад 503 Тимчасовий недоступний сервіс або порожній файл?

Оновлення: Щоб бути більш зрозумілим, я запитую, чому подавати дані зображень GIF, коли вся необхідна інформація вже надіслана в заголовки запитів. Зображення у форматі GIF не повертає корисної інформації.

Відповіді:


70

Відповідь Дага досить вичерпна; Я думав додати в додатковій примітці (на прохання Оператора, від мого коментаря)

Відповідь Дага пояснює, чому маяки 1х1 піксель використовуються з ціллю, для якої вони використовуються; Я думав, що окреслив би потенційний альтернативний підхід, який полягає у використанні коду стану HTTP 204 «Без вмісту» для відповіді та не надсиланні тіла зображення.

204 Без вмісту

Сервер виконав запит, але йому не потрібно повертати тіло сутності, і, можливо, він захоче повернути оновлену інформацію про метаінформацію. Відповідь МОЖЕ включати нову або оновлену інформаційну інформацію у вигляді заголовків сутностей, які, якщо вони є, ПОВИННІ бути пов'язані із запитуваним варіантом.

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

З документації Google Speed ​​Page :

Одним із популярних способів асинхронного запису переглядів сторінок є включення фрагмента JavaScript внизу цільової сторінки (або як обробника події завантаження), який повідомляє сервер реєстрації, коли користувач завантажує сторінку. Найпоширеніший спосіб зробити це - побудувати запит до сервера на "маяк" та кодувати всі цікаві дані як параметри в URL-адресі ресурсу маяка. Щоб відповідь HTTP була дуже малою, прозоре зображення розміром 1х1 піксель є гарним кандидатом для запиту маяка. Дещо оптимальнішим маяком буде відповідь HTTP 204 ("без вмісту"), яка незначно менша за GIF розміром 1х1.

Я ніколи не пробував, але теоретично це повинно виконувати ті самі цілі, не вимагаючи передачі самого gif, заощаджуючи ваші 35 байт, у випадку з Google Analytics. (У схемі речей, якщо ви не використовуєте Google Analytics, що здійснює багато трильйонів звернень на день, 35 байт - це насправді ніщо.)

Ви можете протестувати його за допомогою цього коду:

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

12
Ці менш відомі коди статусу HTTP (203, 204, 205) насправді є золотими. Вони повинні бачити більше користі, ніж зараз.
Ви

1
приємна - насправді інформація, яку я можу використати. +1 від мене.
дуг

1
дозвольте подивитися, чи можу я підсумувати - підхід коду відповіді HTTP передбачає той самий запит клієнта; єдина відмінність полягає в тому, що сервер замість того, щоб повернути gif 1х1 (і 200, я припускаю) замість, повертає клієнту 204?
дуг

2
Як би ви запросили ту річ, яка повертає код відповіді 204?
Юрген Пауль

3
Я не розумію, чому зображення. Чому б не повернути порожній рядок?
Weishi Zeng

65

По-перше, я не погоджуюсь з двома попередніми відповідями - жодне не стосується питання.

Зображення в один піксель вирішує внутрішню проблему веб-програм для аналітики (наприклад, Google Analytics) при роботі в протоколі HTTP - як перенести дані (веб-метрики) з клієнта на сервер .

Найпростіший із методів, описаних Протоколом, найпростіший (принаймні найпростіший метод, що включає тіло запиту) - це запит GET . Відповідно до цього методу протоколу, клієнти ініціюють запити до серверів на ресурси; сервери обробляють ці запити та повертають відповідні відповіді.

Для веб-додатків аналітики, таких як GA, ця односпрямована схема є поганою новиною, оскільки, схоже, вона не дозволяє серверу отримувати дані від клієнта на вимогу - знову ж таки, все, що можуть зробити сервери - це постачати ресурси, а не запитувати їх.

Отже, яке рішення проблеми отримання даних від клієнта назад до сервера? У контексті HTTP існують інші методи протоколу, крім GET (наприклад, POST), але це обмежений варіант з багатьох причин (про що свідчить його рідкісне та спеціалізоване використання, наприклад, подання даних форми).

Якщо ви подивитесь на запит GET із браузера, то побачите, що він складається з URL-адреси запиту та заголовків запитів (наприклад, Referer та User-Agent), останній містить інформацію про клієнта - наприклад, тип браузера та версія, мова браузера, операційна система тощо.

Знову ж таки, це частина запиту, який клієнт надсилає на сервер. Тож ідея, яка мотивує gif-піксель, полягає в тому, щоб клієнт надсилав дані веб-метрик на сервер, загорнувшись у заголовку запиту.

Але як тоді змусити клієнта запитувати ресурс, щоб його можна було "обдурити" надсиланням даних метрик? І як змусити клієнта надіслати фактичні дані, які хоче сервер?

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

Але оскільки метою цього запиту є не фактично отримати ресурс, а надіслати дані на сервер, цей ресурс повинен бути якомога меншим і він не повинен бути видимим при отриманні на веб-сторінці - отже, 1 x 1 піксель прозорий gif. Розмір - це найменший можливий розмір, а формат (gif) - найменший серед форматів зображень.

Точніше, усі дані GA - кожен окремий елемент - збираються та упаковуються у рядок запиту URL-адреси запиту (все після знака „?“). Але для того, щоб ці дані надходили з клієнта (де вони створені) на сервер GA (де вони реєструються та агрегуються), має бути HTTP-запит, тому ga.js (скрипт Google Analytics, який завантажується, якщо він не кешований клієнтом, як результат функції, що викликається при завантаженні сторінки) вказує клієнту збирати всі аналітичні дані - наприклад, файли cookie, рядок розташування, заголовки запитів тощо - об'єднувати їх в один рядок та додайте його як рядок запиту до URL-адреси ( * http: //www.google-analytics.com/__utm.gif* ?), і це стає URL-адресою запиту .

Це легко довести за допомогою будь-якого веб-браузера, який має перегляд HTTP-запиту для веб-сторінки, що відображається у вашому браузері (наприклад, веб-інспектор Safari , 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

Ключові моменти, на які слід звернути увагу:

  1. Запит фактично був запитом на utm.gif, про що свідчить перший рядок вище: * URL-адреса запиту: http: //www.google-analytics.com/__utm.gif*.

  2. Параметри Google Analytics чітко видно у рядку запиту , доданому до URL-адреси запиту : наприклад, utmsr - це назва змінної GA для посилання на роздільну здатність екрана клієнта, для мене показує значення 1280x800; utmfl - ім'я змінної для флеш-версії, яке має значення 10,3 тощо.

  3. Тема відповіді називається Content-Type (відправлений сервер назад клієнт) також підтверджує , що ресурс , запитуваний і повертається був 1x1 пікселі GIF: Content-Type: зображення / GIF

Ця загальна схема передачі даних між клієнтом і сервером існує вічно; цілком може бути кращий спосіб зробити це, але це єдиний спосіб, про який я знаю (який задовольняє обмеження, накладені розміщеною службою аналітики).


3
@doug Казкова відповідь. Я би хотів, щоб я це написав :) Можливо, варто додати примітку про те, що потенційно можна використовувати HTTP Status Code 204для відповіді. Дивіться це: code.google.com/speed/page-speed/docs/rtt.html Я ніколи не пробував, але теоретично це повинно виконувати ті самі цілі, не вимагаючи передачі самого gif. var i=new Image(); i.src = "http://sharedcount.com/test/beacon.gif";є прикладом, але я не впевнений, що це може спричинити проблеми з браузером.
Яхель

9
Це ще не найгірша відповідь, бо це не відповідь :) Я запитав, навіщо взагалі подавати зображення GIF, оскільки необхідні дані вже надіслані із запитом.
Viliam

2
Я не хочу бути занадто негативним, вибачте. Це гарне пояснення веб-помилки. Але навіщо повертати дані GIF назад?
Viliam

@yahelc: це чудово. Подумайте про це, щоб додати як відповідь для інших. Як коментар це майже непомітно.
Viliam

@Villiam впевнений, щойно додав.
Яхель,

14

Деякі браузери можуть відображати піктограму помилки, якщо ресурс не вдалося завантажити. Це також дещо ускладнює налагодження / моніторинг послуги, і ви повинні переконатися, що ваші інструменти моніторингу розглядають помилку як хороший результат.

OTOH ви нічого не отримуєте. Повідомлення про помилку, яке повертає сервер / фреймворк, зазвичай більше, ніж зображення 1x1. Це означає, що ви збільшуєте свій мережевий трафік фактично ні за що.


1
причина, що програми для аналітики (наприклад, Google Analytics, Yahoo Analytics, Omniture та ін.) розміщують зображення GIF розміром 1 × 1 піксель на веб-сторінці, абсолютно нічого спільного не має із «налагодженням» програми.
дуг

3
@doug - Мені здається, головне, що там робить mru, полягає в тому, що якщо ти навмисно повертаєш коди помилок, то ти повинен розрізняти "справжні" коди помилок та коди помилок, які ти мав на меті повернути. Тож мораль історії полягає в тому, що ніколи не повертайте код помилки в результаті, коли саме такий результат і призначений.
Moo,

3
Я сумніваюся, що відповідь на помилку буде більшою, ніж зображення у форматі GIF.
Viliam

2
Більшість середовищ @Villiam не просто повертають код помилки, а й красиво оформлений html-сторінку, що описує помилку / надає більше інформації.
Ульріх Дангель,

8

Оскільки такий GIF має відому презентацію у браузері - це один піксель, крапка. Що-небудь інше представляє ризик візуального втручання у фактичний зміст сторінки.

Помилки HTTP можуть відображатися як великі кадри тексту помилки або навіть як спливаюче вікно. Деякі браузери також можуть скаржитися, якщо отримують порожні відповіді.

Окрім того, внутрішньосторінкові зображення є одним із дуже небагатьох типів даних, дозволених за замовчуванням у всіх браузерах. Для будь-чого іншого може знадобитися завантаження явних дій користувача.


1
у вашій відповіді нічого не сказано про мету обслуговування ресурсу - тобто, чому ресурс взагалі потрібно обслуговувати? Ваша відповідь спрямована на запитання "навіщо подавати gif розміром 1х1 замість іншого формату зображення? Це тривіальне питання з тривіальною відповіддю (тобто формат gif має менший розмір на пікселях за пікселем, ніж jpeg, png , tiff тощо)
дуг

Ви можете викликати завантаження GIF за допомогою об'єкта Javascript Image. Він не повідомляє користувачеві про будь-які помилки.
Viliam

@Villiam По-справжньому повернувши зображення, ви також можете відстежувати браузери без увімкненого JavaScript, просто вставте тег зображення, <noscript>і він буде працювати. І вам не доведеться нічого робити на стороні сервера, щоб розрізнити запити через js (повернення помилки) та запити безпосередньо через елементи в DOM (повернення зображення)
Ульріх Дангел

4

Це має відповісти на запитання ОП - "навіщо подавати дані зображень GIF ..."

Деякі користувачі встановлюють простий тег img для виклику служби реєстрації подій -

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

У цьому випадку, якщо ви не подаєте зображення, браузер покаже піктограму заповнювача, яка буде виглядати потворно і створюватиме враження, що ваша послуга зламана!

Що я роблю, шукаю поле заголовка Accept . Коли ваш скрипт викликається за допомогою тегу img, подібного до цього, ви побачите щось на зразок наступного в заголовку запиту -

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

Коли в полі заголовка Accept є рядок "image / " * , я подаю зображення, інакше я просто відповідаю 204.


2

Ну, головна причина полягає в тому, щоб приєднати до нього файл cookie, тому, якщо користувачі переходять з одного боку на інший, у нас все ще є той самий елемент, до якого потрібно прикріпити файл cookie.


0

Вам не потрібно обслуговувати зображення, якщо ви використовуєте Beacon API ( https://w3c.github.io/beacon/ метод реалізації ).

Код помилки буде працювати, якщо у вас є доступ до файлів журналів вашого сервера. Мета обслуговування зображення - отримати більше даних про користувача, ніж зазвичай, із файлом журналу.


0

@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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.