Internet Explorer ververst pagina constant

[H92!]

Beste,

Ik heb onlangs op een site URL-rewriting toegepast d.m.v. htaccess en sindsdien heb ik het probleem dat Internet Explorer gebruikers (versie 8, 9 en 10) ontzettend veel pageviews genereren. Het lijkt net als deze gebruikers constant op F5 drukken.

Van de oude naar nieuwe situatie:
Oude url: Example.com/pagina.php?id=12345

Als je nu deze oude pagina bezoekt, dan haalt hij uit de database de categorie en titel op en stuurt je met een PHP header 301 naar de nieuwe url:

Nieuw: Example.com/categorie/subcategorie/paginatitel/id-12345/
Wat werkelijk pagina2.php?category=...&subcat=...&title=...&id=...

Nu is het probleem dat bij sommige IE gebruikers de nieuwe URL constant blijft verversen (tot 10x per seconde en dat minuten lang). Ik heb zelf op F5 zitten drukken, en het verbaasde me dat dit inderdaad mogelijk was. De html/PHP output op de nieuwe pagina is hetzelfde gebleven.

Wat heb ik gedaan:

• Gegevens uit cookies lezen uitgeschakeld (geen effect)
• Social media buttons uitgeschakeld (geen effect)
• PHP-code meerdere malen bekeken en kleine dingen verbeterd, geen effect (script komt ook niet in if() waar eventuele header/location-code staat, waardoor het alleen html of de gebruiker de oorzaak kon zijn. Html output was hetzelfde met oude URL)
• Van HTML4 naar HTML5 aanpassingen gedaan, zoals Doctype (af en toe waren HTML5 dingen geïmplementeerd met Doctype HTML4), ook geen effect
• Meta-tags en header in htaccess voor IE gebruikers gaan gebruiken voor compatibility view:
  <meta http-equiv="X-UA-Compatible" content="IE=edge"> en de header in htaccess met de volgende code:
  http://stackoverflow.com/...-in-html5/5763610#5763610

Zelf dacht ik dus uiteindelijk dat het aan de compatibility view van IE ligt, maar helaas ook met de bovenstaande codes doet het probleem zich voor. Toch had ik nog steeds vermoeden dat hier ergens het probleem zit en was hier iets verder mee gaan spelen: op dit moment heb ik op de oude URL een meta-refresh naar de nieuwe URL gedaan ipv PHP header redirect (alleen voor IE gebruikers), en dit heeft ongeveer de driekwart van de onnodige refreshes doen dalen, nu de andere kwart nog.

Het grote probleem misschien is dat ik zelf niet het probleem kan reproduceren en dat het niet onder alle IE gebruikers gebeurt. Zelfs onder de ‘probleemgebruikers’ wordt de ene keer de pagina goed geladen, terwijl de andere keer de pagina constant ververst wordt.

(Op dit moment lijkt het erop dat mensen die voor de URL-wijziging de website al hebben bezocht hier last van hebben, maar dit kan ik niet met zekerheid zeggen)

Heeft iemand een idee wat het probleem zou kunnen zijn en hoe dit valt op te lossen?

[Onbekend]

Zouden ze de pagina (deels) nog uit het cache geheugen laden?
Oftewel, leeg de temporary internet files eens.

[EnnaN]

Ik zou ten eerst eens naar de logging van je webserver kijken. De herhalende requests moeten er heel duidelijk uit te halen zijn, en dan kan je kijken wat (if any) de overeenkomsten zijn.
Voorbeelden van dingen waarna je kan kijken (zomaar uit de hoge hoed getoverd hoor)

* rare useragent
* 'speciaal' request, bijvoorbeeld met extra parameter waardoor je redirect flipt
* ze gaan naar een deeplink die dit gedrag vertoont (hele andere pagina dan jij denkt dus).

Kijk in ieder geval welke pagina actually geladen wordt (zet dus wat error-logging in je php) voor welke mensen. Misschien dat de speciale groep mensen om 1 of andere reden toch naar een andere pagina gaan.

Voor meer debugging help hier is het mss handig om de hele .htaccess hier neer te zetten?

[H92!]

Ik had voor php/html niet expliciet caching ingesteld, maar deze heb ik nu op 0 gezet.

Ik had al naar de logs gekeken, hierbij een stukje:

-- Bezoeker komt binnen --
[24/Aug/2013:23:34:14 +0200] "GET /categorie/subcat/title/id-100477/ HTTP/1.1" 200 3904 "-" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
-- Laadt afbeeldingen --
[24/Aug/2013:23:34:14 +0200] "GET /categorie/subcat/title/id-100477/ HTTP/1.1" 200 3903 "http://www.example.com/categorie/subcat/title/id-100477/" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
[24/Aug/2013:23:34:15 +0200] "GET /categorie/subcat/title/id-100477/ HTTP/1.1" 200 3903 "http://www.example.com/categorie/subcat/title/id-100477/" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
[24/Aug/2013:23:34:15 +0200] "GET /categorie/subcat/title/id-100477/ HTTP/1.1" 200 3903 "http://www.example.com/categorie/subcat/title/id-100477/" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
[24/Aug/2013:23:34:16 +0200] "GET /categorie/subcat/title/id-100477/ HTTP/1.1" 200 3904 "http://www.example.com/categorie/subcat/title/id-100477/" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
-- En nog tientallen regels hetzelfde --

Htacces stukje:

code:

RewriteRule ^([^/]*)/([^/]*)/([^/]*)/id-([^/]*)/$ /pagina2.php?category=$1&subcat=$2&title=$3&id=$4 [L]
<IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
        BrowserMatch MSIE ie
        Header set X-UA-Compatible "IE=Edge,chrome=1" env=ie
    </IfModule>
</IfModule>
<IfModule mod_headers.c>
    Header append Vary User-Agent
</IfModule>

Header gecheckt met web-sniffer en X-UA header wordt goed verstuurd.

[ Voor 9% gewijzigd door H92! op 25-08-2013 11:12 ]

[Bosmonster]

Heb je een base href ingesteld toevallig?

[deTuinman]

is dit dan geen dynamisch url, die je dus kunt uitfilteren in je robots.txt of het gebruik van rel="canonical" ik weet even niet het verschil tussen deze en de base href

[Bosmonster]

Wat betreft die base href: Het gedrag hiervan verschilt nogal per browser. Kan me voorstellen dat IE bijvoorbeeld voor elke request (zoals afbeeldingen) de te rewriten url gebruikt.

Hier kun je natuurlijk relatief makkelijk achterkomen door het verkeer te analyseren.

[ Voor 19% gewijzigd door Bosmonster op 26-08-2013 15:59 ]

[H92!]

@Bosmonster, nee er wordt geen base href gebruikt. In de logs worden de afbeeldingen allemaal 1x goed aangeroepen.

@deTuinman, wat bedoel je precies?

Ook het instellen van no-cache heeft niet geholpen. Ik krijg meer de neiging om dit probleem 'op te lossen' met een pagina "Stap over naar een fatsoenlijke browser".

[H92!]

Mogelijk het probleem gevonden, het ligt aan de manier hoe IE met redirects omgaat.

Misschien was er in het begin (testfase) een redirectfout waardoor een 301 redirect werd gedaan op de nieuwe pagina naar de nieuwe pagina (loop). Deze is gecached door IE en wordt nu niet meer vernieuwd waardoor ze in deze loop blijven op deze pagina.

Het volgende probleem is, deze (redirect)cache van IE is niet te legen via headers/server side, waardoor de gebruiker zelf de browser moet legen. Iemand een idee hoe ik nu de gebruiker uit deze loop haal?