[IIS/ASP] IIS Logging van browser terug actie

[Verwijderd]

Voor op mijn Microsoft IIS 5.0 webserver wil ik graag voor de statistieken van mijn website(s) ook alle "browser back button"/"history.back()" acties vastgelegd hebben in mijn IIS logfiles. Standaard doet IIS logging dat niet, en in ASP werken response.expires=-1 e.d. natuurlijk niet omdat het allemaal aan de client kant gebeurt (de client gaat immers terug naar de lokaal gecachede vorige pagina).

Nou weet ik van Nedstat/Sitestat dat zij een stukje javascript gebruiken dat er voor zorgt dat ook het gebruik van de back button van de browser vastgelegd wordt. Zij vertellen daarover het volgende op hun site:
---------
Met deze meetmethode is Sitestat alle soorten van caching (lokale opslag) te slim af. De Nedstat meetmethode is aantoonbaar de meest betrouwbare en effectieve
---------
Maar hier heb ik verder geen kijk op.
Is er iets waarmee je met javascript kan uitlezen of er een "terug klik actie" is geweest? Dan zou je natuurlijk een image oid op kunnen vragen van de server, wat weer zorgt voor een log entry... Waarschijnlijk is dat ook de methode die zij gebruiken, of in ieder geval een vergelijkbaar iets.

Is er iemand die er ervaring mee heeft om er voor te zorgen dat zijn webserver ook dit soort terug/back button acties vastlegt?

[Verwijderd]

slechts een idee:
1. directe img tag naar een plaatje/asp1 met het site/page id
2. javascript genereert een img tag plaatje/asp2 met een site/page id en een pseudo-random getal als query string (oid iig het gedeelte na ? in de url) variabelen

plaatje 1 wordt 1 maal opgehaald, gecached en 1 maal gelogd met referer
plaatje 2 wordt iedere keer opgehaald door het pseudo-random getal, wederom met rerferer

log entry voor plaatje 1 en 2 aanwezig, page komt niet uit cache
log entry voor alleen plaatje 2, page komt uit cache

je zou ook in javascript op de client kunnen proberen het history object uit te lezen, kijken of history.next iets is.

[Verwijderd]

Hoe moet ik stap 2 zien? Je genereert dan toch lokaal een afbeelding met javascript?

[Verwijderd]

In dit artikel
http://www.cmupdate.nl/artikel.php?artikel_id=301
staat de volgende passage:
Logfile-software ziet alleen de verzoeken die de webserver bereiken, maar sommige acties van de bezoeker gaan daardoor verloren. Als een bezoeker bijvoorbeeld op 'Back' klikt om terug te gaan naar de vorige pagina, komt die pagina uit het geheugen van zijn browser. De webserver, en dus de logfile-software, komt hier niets van te weten. Een ASP-dienst doorgaans wel, omdat aan de pixel een unieke tijdcode wordt geplakt (door middel van javascript), waardoor deze nooit lokaal wordt opgeslagen. Zelfs niet door proxyservers. Alle details van het klikpad worden zo dus zichtbaar. Op die manier is een veel nauwkeuriger inzicht te krijgen in de knelpunten van de site. Moeten bezoekers bijvoorbeeld steeds terug naar de homepage voordat ze een ander artikel kunnen lezen?

Hebben ze bij Nedstat dan een hele stapel pixels opgeslagen? Of zouden ze per dag een hele verzameling pixels opbouwen en deze de volgende dag weer verwijderen?

[WormLord]

Waarschijnlijk hebben ze gewoon een pixel generator. Oftewel een asp/php-script dat de request logt en een pixel naar de client stuurt. Vaak nog in de vorm van een doorzichtig .gif plaatje ook.

[Verwijderd]

ik bedoel zoiets:

HTML:

BLA
rest van de pagina
BLA

[img]"track_htm_blank.gif">
<script[/img]
<!-- //
  getTimeCode() {
    // return timecode;
  }
  document.write('<img src="track_js_blank.gif?t=' + getTimeCode() + '"');
// -->
</script>

[_Thanatos_]

de "vorige' knop kun je niet loggen, omdat er op de server en in javascript niets gebeurt. Ik weet niet precies hoe het gebrekkige IE werkt, maar een goeie browser gaat bij de "vorige"-knop gewoon terug naar waar je vandaan komt, en gaat dus niet allerlei dingen opnieuw uitvoeren/parsen.

[Verwijderd]

_Thanatos_ schreef op donderdag 27 januari 2005 @ 13:30:
de "vorige' knop kun je niet loggen, omdat er op de server en in javascript niets gebeurt. Ik weet niet precies hoe het gebrekkige IE werkt, maar een goeie browser gaat bij de "vorige"-knop gewoon terug naar waar je vandaan komt, en gaat dus niet allerlei dingen opnieuw uitvoeren/parsen.

Nedstat/Sitestat beweert anders heel wat anders... . En het lijkt me toch dat dat werkt met die truuk met het "dynamische" gifje...

[Verwijderd]

ik heb het net even getest met firefox,
die haalt bij het het klikken op back keurig het plaatje op via de JS gegenereerde IMG tag.

hier het server logje

code:

2005-01-27 22:36:16 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/ - 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:18 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/test.html - 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:18 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/blank_html.gif p=test&tag=html&d= 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:18 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/blank_js.gif p=test&tag=js&d=0.7044371663301121 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:23 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/test2.html - 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:23 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/blank_js.gif p=test2&tag=js&d=0.49201706050336924 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:23 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/blank_html.gif p=test2&tag=html&d= 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0
2005-01-27 22:36:26 xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx 80 GET /test-track/blank_js.gif p=test&tag=js&d=0.2833174562565909 200 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.7.5)+Gecko/20041107+Firefox/1.0

getest met 2 paginas (zo ongeveer):
test.html
html link 'test2.html'
html img tag 'blank_html.gif?blabla&d=0'
js generated html img tag 'blank_js.gif?blabla&d=747843'

test2.html
html img tag 'blank_html.gif?blabla&d=0'
js generated html img tag 'blank_js.gif?blabla&d=9823147'


1. test opgehaald (log regel 1-4)
2. in pagina 1 op link naar test2 geklikt (log regel 5-7)
3. op back geklikt (log regel 8 )
zie log

Dus zoals je ziet werkt het dus wel

[ Voor 54% gewijzigd door Verwijderd op 27-01-2005 23:57 ]

[_Thanatos_]

Firefox doet het dus ook niet netjes

[Verwijderd]

@_tahantos_ is inderdaad niet netjes

[Woy]

_Thanatos_ schreef op donderdag 27 januari 2005 @ 23:53:
Firefox doet het dus ook niet netjes

Hoezo niet. Met de back knop wordt netjes de vorige pagina getoond die er in het geheugen van de browser zit. Bij die pagina hoort een javascript wat uitgevoerd wordt als de pagina geladen wordt. Ik vindt het op zich wel netjes gedrag van de browser.

[Verwijderd]

wyshell: erg bedankt in ieder geval.. Dit lijkt inderdaad de methode te zijn die ze toepassen... Ik zal het zelf ook eens implementeren.

[NMe]

rwb schreef op vrijdag 28 januari 2005 @ 00:22:
Hoezo niet. Met de back knop wordt netjes de vorige pagina getoond die er in het geheugen van de browser zit. Bij die pagina hoort een javascript wat uitgevoerd wordt als de pagina geladen wordt. Ik vindt het op zich wel netjes gedrag van de browser.

Dat Javascript heeft zich al eens afgespeeld. Als ik op vorige klik, dan wil ik terug naar de pagina zoals ik die verlaten heb. Dat wil zeggen dat images en dergelijke allemaal hetzelfde zijn en niet herladen dienen te worden. Bovendien is het onzinnig om alle Javascripts opnieuw uit te voeren, want daar vraag je toch niet om?

[Verwijderd]

-NMe- schreef op vrijdag 28 januari 2005 @ 13:50:
[...]

Dat Javascript heeft zich al eens afgespeeld. Als ik op vorige klik, dan wil ik terug naar de pagina zoals ik die verlaten heb.

En daarom moet javascript af en toe wel runnen. Als je namelijk een pagina hebt die naar zichzelf post (komt heel vaak voor in dynamische omgevingen) dan blijft de state (selectie) van bijvoorbeeld een dropdown behouden als je op back drukt. Dit is voor de gebruiker niet logisch, want voor haar hoorde de vorige selectie van de dropdown bij de vorige pagina. Dit geldt in iets mindere mate voor pagina's waar je eerst een selectie verander en dan op show oid druk, maar juist wel voor pagina's waar een selectie in de drop-down je na een nieuwe pagina brengt.
Via een (onload) javascript kun je de selecties van dropdowns dan terugzetten naar de waardes die vanaf de server gegenereerd werden voor een bepaalde 'versie' van een dynamische pagina.

[_Thanatos_]

dan blijft de state (selectie) van bijvoorbeeld een dropdown behouden als je op back drukt

In Opera werkt dat ook zo. Als een pagina naar zichzelfs post (postback) dan kun je keurig door die postbacks heen en weer met back/forward.

[NMe]

Verwijderd schreef op vrijdag 28 januari 2005 @ 14:33:
En daarom moet javascript af en toe wel runnen. Als je namelijk een pagina hebt die naar zichzelf post (komt heel vaak voor in dynamische omgevingen) dan blijft de state (selectie) van bijvoorbeeld een dropdown behouden als je op back drukt. Dit is voor de gebruiker niet logisch, want voor haar hoorde de vorige selectie van de dropdown bij de vorige pagina.

Nee hoor. Als ik op vorige klik, dan verwacht ik exact dezelfde pagina die ik achterliet. Formulieren die ik al ingevuld had behoren nog ingevuld te zijn, selecties ook. Wanneer een script daar wat aan wil veranderen, dan is dat script IMHO fout bezig. Ik vind ook dat een browser zoiets behoort tegen te houden.

[Verwijderd]

-NMe- schreef op vrijdag 28 januari 2005 @ 14:38:
[...]

Nee hoor. Als ik op vorige klik, dan verwacht ik exact dezelfde pagina die ik achterliet.

Ja hoor. Daarom is dat ook zo. Als jij op de huidige pagina een selector verander waardoor je -meteen- naar de volgende pagina springt, dan zag jij die selection helemaal niet als onderdeel van die vorige pagina maar alleen als een commando wat je gaf.

Ga je echter terug naar die pagina dan staat die selector zonder verdere maatregelen nog in de stand van hoe je hem veranderd had (maar die jij nog niet echt gezien had omdat je meteen naar de vorige pagina jumpte).

Het is soms wel de vraag van wat de gebruiker wil, de pagina zoals de server hem stuurde of de pagina zoals je hem het laatst veranderd had. Stel de server stuurt mijn een pagina met een datum selector en data die bij die datum A hoort. Ik verander de selector naar datum B en druk op toon. Ik krijg nu data die bij datum B hoort. Druk ik op de back-button, dan is mijn selector nog steeds datum B, maar de data die op de pagina staat hoort bij datum A.

Veel users willen in het bovenstaande geval dat de selector dan overeenkomt met wat de pagina weergeeft. In andere sitiaties echter (het invullen van een form bijvoorbeeld) wil je juist wel weer dat bij een back je de dingen krijgt zoals de user ze het laatst ingevuld heeft.

Daarom kun je met javascript een keuze maken. Dat het reageert op de back-button is dus goed; er zijn tal van situaties waarin het absoluut gewenst gedrag is.

[Verwijderd]

Niet getest:

Zoals eerder beschreven, een transparant gifje erop gooien met JS aan het einde waarin een timestamp gezet wordt.
Als je terug gaat wordt de code weer geparst. Wellicht dat de JS timestamp die van nu pakt, en niet van de vorige keer zodat de afbeelding opnieuw geladen word? (afbeelding met de nieuwe timestamp staat niet in de cache)

http://url/img.gif?t=449287070