[IIS] 304 forceren

[GrimaceODespair]

Ik heb een IIS-site die een bepaalde afbeelding bevat die ik graag voor tracking doeleinden wil gebruiken. De tracking gebeurt doordat ik in de IIS logs kan zien dat er een request is geweest. Dat kan alleen als de afbeelding niet gecached wordt door de browser.

Nu kan ik in IIS voor de betreffende afbeelding de "content expiration" op "expire immediately":

	---- request ---->
IE		IIS
	<-- 200 + image --

In dat geval bevat de payload van de response echter altijd de volledige image data. Dat zou ik willen vermijden door een 304 door IIS te laten forceren:

	-- request -->
IE		IIS
	<-- 304 --

Via het tweaken van de IIS settings krijg ik echter maar 2 scenario's aan de gang krijg die net niet doen wat ik wil:

Scenario	Goed	Fout
200	IIS request vindt altijd plaats (tracking!), ook binnen 1 IE sessie	De volledige image wordt ook altijd mee gedownload
304	Er vindt geen IIS request plaats binnen dezelfde IE sessie (geen tracking!). Het beste wat ik krijg, is dat IE na een herstart opnieuw een request plaatst	De volledige image wordt alleen de 1e keer gedownload

Als ik dit zou kunnen oplossen zonder Javascript, zou ik zeer gelukkig zijn. Ik weet alleen niet of dat mogelijk is. Iemand?

edit:
Toch wel enigszins relevant: de omgeving is ASP.NET 2.0 op IIS 6.0

[ Voor 2% gewijzigd door GrimaceODespair op 11-05-2007 17:42 . Reden: owja... ]

[StapelPanda]

bij php kan je een header meegeven, misschien kan je dit ook met je ASP.NET

PHP:

<?php
header("HTTP/1.0 403 Forbidden");
?> 

[MTWZZ]

Kun je niet gewoon een aparte ASP.net pagina maken en dan als src opgeven in een 0 x0 px image.
In die ASP.Net pagina kun je eventueel via de sessie bepalen of er al een request is geweest en bij het 1e request ergens in een logfile of database een regeltje wegschrijven. Op die manier heb je veel meer controle en kun je eventueel meer gegevens van de client vastleggen dan alleen dat er een request is geweest.

[The - DDD]

Ik zou eerder zeggen... waarom een image gebruiken voor tracking?

Je hebt toegang tot de logs lees ik, dan is het toch helemaal niet meer nodig om aan gekunstelde tracking te gaan doen met plaatjes? Ok, misschien makkelijker te parsen, maar dat voordeel vind ik niet noemenswaardig.

[crisp]

Als het om een 1x1 tracking image gaat denk ik dat je beter gewoon het plaatje kan doorsturen dan de extra noodzakelijke headers (expires/max-age must-revalidate) en de serverside logic om adhv If_Modified_Since een 304 terug te sturen - de headers zijn waarschijnlijk groter dan je plaatje zelf en het past nog steeds in 1 TCP/IP packet.

[SKiLLa]

Zie ook deze deze url op w3.org over HTML status-codes. Zoek je geen 307 (of 302) ? Indien je alternative (content) response stuurt (dus niet uitsluitend headers), moet je inderdaad "no-cache", etc. ... headers mee te sturen, ala (ASP):

code:

<%
Response.AddHeader      "Pragma", "no-cache" ' HTTP 1.0
Response.CacheControl = "no-cache"           ' HTTP 1.1
Response.Expires      = 0
%>

[ Voor 21% gewijzigd door SKiLLa op 12-05-2007 00:34 ]

[GrimaceODespair]

Gieltjev schreef op vrijdag 11 mei 2007 @ 18:21:
bij php kan je een header meegeven, misschien kan je dit ook met je ASP.NET

Als ik de ASP.NET pipeline niet inhoef, zou dat mooi zijn, oa voor performance.

The - DDD schreef op zaterdag 12 mei 2007 @ 00:04:
Ik zou eerder zeggen... waarom een image gebruiken voor tracking?

Je hebt toegang tot de logs lees ik

Het stelt mij in staat om via url rewriting en de IIS logs een standaardstatistiekenpakket te gebruiken om bepaalde informatie te verzamelen. De pagina's worden op zich al getrackt op de manier die je voorstelt, maar op die pagina's komen ook nog eens tracking pixels voor. Ik zeg niet dat het de mooiste manier is, maar wel de gemakkelijkste om te bereiken wat ik wil (tenzij dat IIS verhaal niet lukt natuurlijk).

crisp schreef op zaterdag 12 mei 2007 @ 00:18:
Als het om een 1x1 tracking image gaat denk ik dat je beter gewoon het plaatje kan doorsturen [...] de headers zijn waarschijnlijk groter dan je plaatje zelf

Ja, eigenlijk wel een goeie opmerking. Ik heb het grootteverschil eigenlijk nog niet onder de loupe genomen of het delayverschil tussen 200 en 304.

SKiLLa schreef op zaterdag 12 mei 2007 @ 00:29:
Zoek je geen 307 (of 302) ?

Hmm... zou ik even moeten testen.

[StapelPanda]

[verkeerde topic :(]

[ Voor 82% gewijzigd door StapelPanda op 12-05-2007 11:14 ]