Neden 1x1 piksel GIF (web hataları) verisi sunasınız?


81

Birçok analitik ve izleme aracı, etki alanları arası olay depolama / işleme için 1x1 GIF görüntüsü (web hatası, kullanıcı için görünmez) istiyor.

Neden bu GIF görüntüsünü sunmalıyım? 503 Service Temporary Unavailable veya boş dosya gibi bir hata kodunu basitçe döndürmek daha verimli olmaz mıydı ?

Güncelleme: Daha açık olmak gerekirse , gerekli tüm bilgiler istek başlıklarında zaten gönderilmişken neden GIF resim verilerinin sunulacağını soruyorum . GIF görüntüsünün kendisi herhangi bir yararlı bilgi döndürmez.

Yanıtlar:


70

Doug'un cevabı oldukça kapsamlı; Ek bir not eklemeyi düşündüm (OP'nin talebi üzerine, yorumum dışında)

Doug'ın cevabı, 1x1 piksel işaretçilerinin neden kullanıldıkları amaçla kullanıldığını açıklıyor; Yanıt için HTTP Durum Kodu 204, İçerik Yok'u kullanmak ve bir resim gövdesi göndermemek gibi olası bir alternatif yaklaşımın ana hatlarını çizeceğimi düşündüm.

204 İçerik Yok

Sunucu isteği yerine getirdi, ancak bir varlık gövdesi döndürmesi gerekmiyor ve güncellenmiş meta bilgileri döndürmek isteyebilir. Yanıt, mevcutsa istenen varyantla ilişkilendirilmesi GEREKEN, varlık başlıkları biçiminde yeni veya güncellenmiş meta bilgileri İÇEREBİLİR.

Temel olarak, sunucu isteği alır ve bir gövde göndermemeye karar verir (bu durumda, bir görüntü göndermemeye). Ancak ajana bunun bilinçli bir karar olduğunu bildirmek için bir kodla yanıt verir; temelde olumlu yanıt vermenin daha kısa bir yolu.

Gönderen Google Page Speed belgelerinde :

Sayfa görüntülemelerini eşzamansız bir şekilde kaydetmenin popüler bir yolu, hedef sayfanın altına (veya bir yükleme olay işleyicisi olarak) bir kullanıcı sayfayı yüklediğinde günlük sunucusuna bildirimde bulunan bir JavaScript parçacığı eklemektir. Bunu yapmanın en yaygın yolu, sunucuya bir "işaret" için bir istek oluşturmak ve ilgilenilen tüm verileri işaret kaynağı için URL'deki parametreler olarak kodlamaktır. HTTP yanıtını çok küçük tutmak için, şeffaf 1x1 piksel görüntü, bir işaret isteği için iyi bir adaydır. Biraz daha optimal bir işaret, 1x1 GIF'den marjinal olarak daha küçük olan bir HTTP 204 yanıtı ("içerik yok") kullanır.

Bunu hiç denemedim, ancak teoride, gifin kendisinin iletilmesini gerektirmeden aynı amaca hizmet etmeli ve Google Analytics söz konusu olduğunda size 35 bayt tasarruf ettirmelidir. (Plana göre, günde trilyonlarca isabet sunan Google Analytics değilseniz, 35 bayt gerçekten hiçbir şey değildir.)

Bu kodla test edebilirsiniz:

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

12
Bu daha az bilinen HTTP durum kodları (203, 204, 205) gerçekten altındır. Şu anda gördüklerinden daha fazla kullanım görmeliler.
Sen

1
güzel bir - aslında kullanabileceğim bilgiler. Benden +1.
doug

1
özetleyebilir miyim bir bakayım - HTTP yanıt kodu yaklaşımı aynı istemci isteğini içerir ; tek fark sunucunun 1x1 gif (ve sanırım 200) döndürmek yerine istemciye 204 döndürmesidir?
doug

2
Yine de 204 yanıt kodunu döndüren o şeyi nasıl talep edersiniz?
Jürgen Paul

3
Neden imajını anlamıyorum. Neden boş bir dize döndürmüyorsunuz?
Weishi Zeng

65

Birincisi, önceki iki cevaba katılmıyorum - ne soruyu meşgul etmiyor.

Tek piksellik görüntü, HTTP Protokolünde çalışırken (web ölçümleri) verilerin istemciden sunucuya nasıl aktarılacağı gibi web tabanlı analiz uygulamaları (Google Analytics gibi) için içsel bir sorunu çözer .

Protokol tarafından açıklanan yöntemlerin en basiti, en basit olanı (en azından bir istek gövdesi içeren en basit yöntem) GET isteğidir . Bu Protokol yöntemine göre, istemciler sunuculara kaynaklar için istekler başlatır; sunucular bu istekleri işler ve uygun yanıtları döndürür.

GA gibi web tabanlı bir analiz uygulaması için bu tek yönlü şema kötü bir haberdir, çünkü bir sunucunun talep üzerine bir istemciden veri almasına izin vermez - yine, tüm sunucuların yapabileceği şey, onları isteyin.

Öyleyse istemciden sunucuya geri veri alma sorununun çözümü nedir? HTTP bağlamında, GET dışında başka Protokol yöntemleri de vardır (örneğin, POST), ancak bu, birçok nedenden dolayı sınırlı bir seçenektir (form verilerini göndermek gibi seyrek ve özel kullanımıyla kanıtlandığı üzere).

Bir tarayıcıdan bir GET İsteğine bakarsanız, bunun bir İstek URL'sinden ve İstek Başlığından (örneğin, Yönlendiren ve Kullanıcı-Aracı Başlıkları) oluştuğunu görürsünüz ; ikincisi, istemci hakkında bilgiler içerir - ör. Tarayıcı türü ve sürüm, tarayıcı dili, işletim sistemi vb.

Yine, bu, istemcinin sunucuya gönderdiği İsteğin bir parçasıdır. Dolayısıyla , tek pikselli gif'i motive eden fikir, istemcinin web ölçüm verilerini sunucuya bir İstek Başlığı içine sarılmış olarak göndermesidir.

Ama sonra , müşterinin metrik verilerini gönderirken "kandırılabilmesi" için bir kaynak talep etmesini nasıl sağlayabilirim? Ve istemcinin sunucunun istediği gerçek verileri göndermesini nasıl sağlayabilirim?

Google Analytics iyi bir örnektir: ga.js dosyası (istemciye indirilmesi web sayfasındaki küçük bir komut dosyası tarafından tetiklenen büyük dosya) , istemciyi belirli bir kaynaktan belirli bir kaynak istemeye yönlendiren birkaç satır kod içerir. sunucu (GA sunucusu) ve İstek Başlığına sarılmış belirli verileri göndermek için.

Ancak bu İsteğin amacı aslında bir kaynak elde etmek değil, sunucuya veri göndermek olduğundan, bu kaynak olabildiğince küçük olmalı ve web sayfasında görüntülendiğinde görünmemelidir - dolayısıyla 1 x 1 piksel şeffaf gif. Boyut, mümkün olan en küçük boyuttur ve biçim (gif), görüntü biçimleri arasında en küçük olanıdır.

Daha doğrusu, tüm GA verileri - her bir öğe - toplanır ve İstek URL'sinin sorgu dizesine ("?" İşaretinden sonraki her şey) paketlenir . Ancak, bu verilerin istemciden (oluşturulduğu yer) GA sunucusuna (günlüğe kaydedildiği ve toplandığı yer) gitmesi için bir HTTP İsteği olması gerekir, bu nedenle ga.js (google analytics komut dosyası indirilirse İstemci tarafından önbelleğe alınan, sayfa yüklendiğinde çağrılan bir işlevin sonucu olarak) istemciyi tüm analitik verilerini bir araya getirmeye yönlendirir - örneğin tanımlama bilgileri, konum çubuğu, istek başlıkları vb. - bunu tek bir dizede birleştirin ve bunu bir URL'ye sorgu dizesi olarak ekleyin ( * http: //www.google-analytics.com/__utm.gif* ?) ve bu, İstek URL'si olur .

Tarayıcınızda görüntülenen web sayfası için HTTP İsteğini görüntülemenizi sağlayan herhangi bir web tarayıcısını kullanarak bunu kanıtlamak kolaydır (örn., Safari'nin Web Denetçisi , Firefox / Chrome Firebug , vb.).

Örneğin, bir kurumsal ana sayfaya geçerli bir url'yi tarayıcımın konum çubuğuna yazdım ve bu ana sayfayı döndürdüm ve tarayıcımda görüntüledim (ana analitik uygulamalarından birini (GA) kullanan herhangi bir web sitesini / sayfasını seçebilirdim. , Omniture, Coremetrics vb.)

Kullandığım tarayıcı Safari idi, bu yüzden menü çubuğunda Geliştir'i ve ardından Web Denetçisini Göster'i tıkladım . Web Denetçisi'nin en üst satırında Kaynaklar'a tıklayın, sol sütunda gösterilen kaynaklar listesinden utm.gif kaynağını bulup tıklayın, ardından Başlıklar sekmesine tıklayın. Bu size şöyle bir şey gösterecek:

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

Dikkat edilmesi gereken temel noktalar şunlardır:

  1. Yukarıdaki ilk satırda gösterildiği gibi, İstek aslında utm.gif için bir istektir: * İstek URL'si: http: //www.google-analytics.com/__utm.gif*.

  2. Google Analytics parametreleri, İstek URL'sine eklenen sorgu dizesinde açıkça görülebilir : örneğin, utmsr , GA'nın istemci ekran çözünürlüğüne atıfta bulunan değişken adıdır, benim için 1280x800 değerini gösterir; utmfl , 10.3 vb. bir değere sahip flash sürümünün değişken adıdır.

  3. Tepki Başlık denilen Content-Type : (istemci sunucu arka tarafından gönderilen) kaynak istenen ve döndürülen 1x1 piksel gif olduğunu da doğruladı Content-Type: image / gif

Bir istemci ile bir sunucu arasında veri aktarımı için bu genel şema, sonsuza kadar sürdü; bunu yapmanın daha iyi bir yolu olabilir, ancak bildiğim tek yol bu (barındırılan bir analitik hizmetinin getirdiği kısıtlamaları tatmin eden).


3
@doug Harika cevap. Keşke yazsaydım :) HTTP Status Code 204Bir yanıt için kullanabilme potansiyeli hakkında bir not atmaya değer olabilir . Şuna bakın: code.google.com/speed/page-speed/docs/rtt.html Bunu hiç denemedim, ancak teoride gif'in kendisinin iletilmesini gerektirmeden aynı amaca hizmet etmelidir. var i=new Image(); i.src = "http://sharedcount.com/test/beacon.gif";bir örnektir, ancak herhangi bir tarayıcı sorunu oluşturup oluşturmayacağından emin değilim.
Yahel

9
Bu şimdiye kadarki en kötü cevap değil çünkü cevap değil :) GIF resmini neden sunmam gerektiğini sordum, çünkü gerekli veriler zaten istekle birlikte gönderildi.
Viliam

2
Üzgünüm, çok olumsuz olmak istemiyorum. Bu, web bug'ının güzel açıklaması. Ama neden GIF verilerini geri sunmalı?
Viliam

@yahelc: bu harika. Başkaları için bir cevap olarak eklemeyi düşünün. Bir yorum olarak neredeyse görünmez.
Viliam

@Villiam tabi, yeni ekledi.
Yahel

14

Kaynak yüklenemezse bazı tarayıcılar bir hata simgesi görüntüleyebilir. Hizmetin hata ayıklamasını / izlemeyi de biraz daha karmaşık hale getirir, izleme araçlarınızın hatayı iyi bir sonuç olarak ele aldığından emin olmanız gerekir.

OTOH hiçbir şey kazanmazsınız. Sunucu / çerçeve tarafından döndürülen hata mesajı tipik olarak 1x1 görüntüden daha büyüktür. Bu, ağ trafiğinizi temelde hiçbir şey yapmadan artırmanız anlamına gelir.


1
analitik uygulamalarının (ör. Google Analytics, Yahoo Analytics, Omniture ve diğerleri) web sayfasına 1x1 piksellik bir gif görüntüsü yerleştirmesinin uygulamada "hata ayıklama" ile kesinlikle hiçbir ilgisi yoktur.
doug

3
@doug - bence mru'nun orada değindiği nokta, kasıtlı olarak hata kodlarını döndürürseniz, "gerçek" hata kodları ile döndürmek istediğiniz hata kodlarını birbirinden ayırmanız gerektiğidir. Öyleyse, hikayenin ahlaki, sonuç olarak amaçlanan sonuç olduğunda asla bir hata kodu döndürmeyin.
Moo

3
Hata yanıtının GIF görüntüsünden daha büyük olacağından şüpheliyim - GIF görüntüsüyle birlikte gönderilen yanıtın 200 OK olduğunu unutmayın.
Viliam

2
@Villiam çoğu ortam yalnızca hata kodunu döndürmez, aynı zamanda hatayı açıklayan / daha fazla bilgi sağlayan güzel tasarlanmış bir html sayfası da döndürür.
Ulrich Dangel

8

Böyle bir GIF'in tarayıcıda bilinen bir sunumu olduğundan - bu tek bir pikseldir, nokta. Başka herhangi bir şey, sayfanın gerçek içeriğine görsel olarak müdahale etme riski taşır.

HTTP hataları, büyük boyutlu hata metni çerçeveleri veya hatta bir açılır pencere olarak görünebilir. Bazı tarayıcılar da boş yanıtlar alırsa şikayet edebilir.

Ek olarak, sayfa içi resimler, tüm tarayıcılarda varsayılan olarak izin verilen çok az veri türünden biridir. Diğer her şey, açık kullanıcı eyleminin indirilmesini gerektirebilir.


1
Cevabınız kaynağa hizmet etme amacı hakkında hiçbir şey söylemiyor - yani, neden bir kaynağa hizmet verilmesi gerekiyor? Cevabınız, "neden başka tür bir görüntü biçimi yerine 1x1 gif sunun? Bu önemsiz bir sorudur (ör. Gif biçimi, piksel bazında jpeg, png'den daha küçük bir boyuta sahiptir. , tiff, vb.)
doug

Javascript Image nesnesi ile GIF yüklemesini başlatabilirsiniz. Kullanıcıya herhangi bir hata bildirmez.
Viliam

@Villiam Görüntüyü gerçekten döndürerek, javascript etkinleştirilmemiş tarayıcıları da izleyebilirsiniz, sadece görüntü etiketini yerleştirin <noscript>ve çalışacaktır. Ve js yoluyla (bir hata döndürerek) istekleri doğrudan
DOM'daki

4

Bu, OP'nin sorusuna cevap vermek içindir - "neden GIF resim verileri sunulmalı ..."

Bazı kullanıcılar olay günlüğü hizmetinizi çağırmak için basit bir img etiketi koyacaktır -

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

Bu durumda, bir resim sunmazsanız, tarayıcı çirkin görünecek ve hizmetinizin bozuk olduğu izlenimini verecek bir yer tutucu simgesi gösterecektir!

Yaptığım şey, Kabul Et başlık alanını aramaktır. Komut dosyanız böyle bir img etiketi aracılığıyla çağrıldığında , isteğin başlığında aşağıdaki gibi bir şey göreceksiniz -

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

Olduğunda "image / " * dize Kabul başlık alanı, aksi halde ben sadece 204 ile cevap görüntüyü kaynağı.


2

Bunun başlıca nedeni, çerezi ona eklemektir, böylece kullanıcılar bir taraftan diğerine giderse, yine de çerez eklemek için aynı öğeye sahibiz.


0

Beacon API ( https://w3c.github.io/beacon/ ) uygulama yöntemini kullanıyorsanız bir görüntü sunmanız gerekmez .

Sunucunuzun günlük dosyalarına erişiminiz varsa bir hata kodu işe yarayacaktır. Görüntünün sunulmasının amacı, kullanıcı hakkında normalde bir günlük dosyasıyla elde edeceğinizden daha fazla veri elde etmektir.


0

@Maciej Perliński temelde doğru, ancak ayrıntılı bir cevabın faydalı olacağını düşünüyorum.

neden 1x1 GIF ve 204 No-Contentdurum kodu değil ?

204 No-Content sunucunun tüm yanıt başlıklarını (Content-Type, Content-Length, Content-Encoding, Cache-Control vb.) çıkarmasına ve 0 baytlık boş bir yanıt gövdesi döndürmesine (ve çok fazla gereksiz bant genişliğinden tasarruf etmesine) olanak tanır.

Tarayıcılar 204 No-Contentyanıtlara saygı duymaları gerektiğini ve yanıt başlıkları ve yanıt gövdesini beklememeleri gerektiğini bilirler .

sunucunun herhangi bir yanıt başlığı ayarlaması gerekiyorsa (örneğin cache-controlveya cookie), 204 No-Contenttarayıcılar tasarım gereği herhangi bir yanıt başlığını yoksayacağından (HTTP protokol özelliklerine göre) kullanamaz .

Neden 1x1 GIF ve durum kodlu bir Content-Length: 0başlık değil 200 OK?

Muhtemelen birkaç sorunun karışımı, birkaçını saymak gerekirse:

  • eski tarayıcı uyumluluğu
  • Tarayıcılarda MIME türü kontrolleri, 0 bayt geçerli bir görüntü değil.
  • 200 OK 0 bayt ile ara proxy sunucuları ve VPN'ler tarafından tam olarak desteklenmeyebilir
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.