[JS/Ajax] JavaScript werkt niet op IE (klassieker)

[Orwell]

Beginnen met een minfied script is natuurlijk leuk, maar om de lezer niet dol te laten draaien:

JavaScript:

function chat(cpag,npag,citm,nitm){
    var pre=new Date().getTime();
    if(cpag||citm||window.npag==undefined||window.nitm==undefined){
        if(cpag||window.npag==undefined){
            window.npag=npag;
            document.getElementById("commentform").com.focus();
        }
        if(citm||window.nitm==undefined){
            window.nitm=nitm;
            document.getElementById("commentform").com.focus();
        }
        var menu=new XMLHttpRequest();
        menu.open("GET","menuwrite.php?npag="+window.npag+"&nitm="+window.nitm,true);
        menu.setRequestHeader("Content-Type","text/html");
        menu.onreadystatechange=function(){
            if(menu.readyState==4&&menu.status==200){
                document.getElementById("pages").innerHTML=menu.responseText;
                document.getElementById("listpost").style.height=Math.round(0.98*window.innerHeight-179,0)+"px";
            }
        }
        menu.send();
    }
    var post=new XMLHttpRequest();
    post.open("GET","dbwrite.php?npag="+window.npag+"&nitm="+window.nitm,true);
    post.setRequestHeader("Content-Type","text/html");
    post.onreadystatechange=function(){
        if(post.readyState==4&&post.status==200){
            document.getElementById("listpost").innerHTML=post.responseText;
            document.getElementById("duration").innerHTML=new Date().getTime()-pre;
            if(!cpag&&!citm){
                setTimeout("chat(false,"+window.npag+",false,"+window.nitm+")",1000);
            }
        }
    }
    post.send();
}

Ik heb het een beetje leesbaarder gemaakt her en der tijdens postmaken, dus er kan wat gaars ingeslopen zijn wat NIET de oorzaak is van het probleem

Goed, het werkt weer is niet. Maar wat werkt er dan niet, TS? Nou, een chatboxje dat ik men een andere tweak0rz heb gemaakt. Deze chatbox ververst zichzelf om de seconde met Ajax. Die Ajax runt een PHP-paginaatje. En de PHP plukt de chat uit een database. Pretty much all there is.

Dit werkt natuurlijk allemaal goed op alternatieve browsers, maar het werkt niet op IE (standaardverhaal). Of tenminste, IE9. Wat de code doet:

• De code wordt elke seconde aangeroepen. De tijd wordt opgeslagen
• Als we van pagina verwisselen: werk inhoudsopgave bij.
• Als we de pagina openen voor het eerst of bij Submit, focus op tekstveld.
• Werk dan met een PHP-scriptje dat HTML-code spuugt de inhoudsopgave-div bij. Anync a.u.b.
• En werk wel gewoon altijd de div met de posts bij. Ook Ajax, ook async.
• Zijn we klaar? Schrijf tijd op, doe een timeout en lijn pagina mooi uit zodat de CSS3 er des te beter uitziet.

Maar IE9 returnt 304. Oftewel ongewijzigd. Wat een lulverhaal is. Vage is wel dat er al eens een keer magic fix is geweest. Tijdje later unfix. Ook magic. Nu snappen we er dus helemaal niks meer van. Wat we al gedaan hebben:

• De consoles van de browsers op fouten aflopen, niks gevonden. Alle browsers waar we moeilijk om doen passen (FF3,IE8+).
• Het honderdmiljoen keer proberen. Werkt niet.
• Het cache van IE9 clearen. Dan gaat 'ie gelijk weer verder. Eén keertje dan.
• De GET returnt verder geen foutcodes.
• Er wijzigt ook niks, want de laadtijd is 2ms (70-100ms is wat de andere browsers halen).

Los daarvan zijn algemene tips over dit scriptje en het tempo ervan natuurlijk zeer welkom.

Er gebeuren namelijk gare dingen met de benchmarkscores van dit ding. Browsers als IE7 op een Pentium M op een PC die 99% op pagefile draait haalt letterlijk 80ms, terwijl Chrome er gewoon 110ms van bakt.

[RobIII]

Makkelijkste fix? Mikker een random getal in de requeststring:

JavaScript:

menu.open("GET","foo.php?x="+foo+"&y="+bar+"&r="+(Math.floor(Math.random()*9999999)),true);

Vervolgens negeer je de "r" (in dit geval) server-side gewoon.

Je moet sowieso naar je HTTP headers gaan kijken of je de juiste caching instructies verstuurt; maar daar bovenop kan bovenstaande fix nooit geen kwaad.

Orwell schreef op woensdag 18 mei 2011 @ 21:33:
Los daarvan zijn algemene tips over dit scriptje en het tempo ervan natuurlijk zeer welkom.

Het is hier geen rate-my-code Concrete vragen zijn echter welkom.
Als ik dan toch om input gevraagd wordt: waarom vind je het wiel opnieuw uit? Waarom gebruik je geen bestaande "AJAX (enabled) library"? Je probleem is namelijk al honderd miljard keer door jan-en-alleman ondervonden en opgelost; dat had je een hoop tijd bespaard Zelfs GoT loopt over van de topics in dezelfde strekking.

Orwell schreef op woensdag 18 mei 2011 @ 21:33:
Browsers als IE7 op een Pentium M op een PC die 99% op pagefile draait haalt letterlijk 80ms, terwijl Chrome er gewoon 110ms van bakt.

Meten == weten. Waar gaat de meeste tijd in die 110ms in zitten dan? Chrome heeft uitstekende tools aan boord om dat soort zaken te pinpointen / troubleshooten.

[Voor 126% gewijzigd door RobIII op 18-05-2011 21:48]

[Orwell]

RobIII schreef op woensdag 18 mei 2011 @ 21:37:
Makkelijkste fix? Mikker een random getal in de requeststring:

JavaScript:

menu.open("GET","foo.php?x="+foo+"&y="+bar+"&r="+(Math.floor(Math.random()*9999999)),true);

Vervolgens negeer je de "r" (in dit geval) server-side gewoon.

Random. Dit is zeker random. En het werkt nog ook. Als ik het mag geloven van Dramatic gooit IE hiermee zijn cache leeg (als dus de link onbekend/random is). Is mooi, en dankuzeer. Is nog nooit zoiets zo snel gefixt.

RobIII schreef op woensdag 18 mei 2011 @ 21:37:
Je moet sowieso naar je HTTP headers gaan kijken of je de juiste caching instructies verstuurt; maar daar bovenop kan bovenstaande fix nooit geen kwaad.

Dat staat wel goed, vreest niet. Netjes gzip met text/html. Meer mag je namelijk niet instellen van Chrome.

Dankuzeer.

[RobIII]

Orwell schreef op woensdag 18 mei 2011 @ 21:48:
Dat staat wel goed, vreest niet. Netjes gzip met text/html. Meer mag je namelijk niet instellen van Chrome.

Ik vreest nu juist helemaal
gzip (compressie) en text/html (content-type) heeft namelijk geen drol te maken met caching headers (die, granted, alleen als overeenkomst hebben dat ze ook tussen de andere HTTP headers worden meegestuurd). En dat je van Chrome niet meer zou mogen instellen slaat al helemaal als een tang op een varken

Iets met een klepel die de klok misslaat ofzo

---

edit1:
Dit zijn, bijvoorbeeld, de HTTP headers die ik van GoT terugkrijg voor een bepaalde request:

code:

Cache-Control:private, post-check=1, pre-check=2, max-age=1, must-revalidate
Connection:close
Content-Encoding:gzip
Content-Type:text/html; charset=ISO-8859-15
Date:Wed, 18 May 2011 19:57:00 GMT
Expires:Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified:Wed, 18 May 2011 19:57:00 GMT
P3P:CP="CUR ADM OUR NOR STA NID"
Server:Apache/2.2.17 (Debian) mod_ssl/2.2.17 OpenSSL/1.0.0d
Set-Cookie:LastVisit=1305748620; expires=Fri, 17-Jun-2011 19:57:00 GMT; path=/; domain=.tweakers.net
SessionTime=1305745216; expires=Fri, 17-Jun-2011 19:57:00 GMT; path=/; domain=.tweakers.net
Transfer-Encoding:chunked
Vary:Accept-Encoding

En dat werkt, uiteraard, prima in Chrome. Dus waar je de wijsheid vandaan hebt dat je niet meer mag instellen is mij een raadsel

edit2:

Orwell schreef op woensdag 18 mei 2011 @ 21:48:
Als ik het mag geloven van Dramatic gooit IE hiermee zijn cache leeg (als dus de link onbekend/random is).

IE gooit de cache niet leeg. Omdat de URL telkens verschilt (en deze dus nog niet in de cache staat) kan IE niet terugvallen op ge-cachete resultaten en wordt daarmee dus geforceerd een request te versturen naar de server. Dat is iets anders dan "zijn cache leeg gooien"

edit43 :
Oh, en by the way, multi-user-topicstarts (lees: medeauteurs) zijn bedoeld voor het "samen" onderhouden van een topicstart in (bijv. of bijv.) "grote topics"; medeauteurs zijn niet bedoeld om ze ook meteen in 't topic te betrekken; daar kunnen ze zélf een (zinvolle a.u.b.!) post voor in het topic doen of gewoon het topic bookmarken

[Voor 78% gewijzigd door RobIII op 18-05-2011 22:09]

[Dramatic]

RobIII schreef op woensdag 18 mei 2011 @ 21:51:
IE gooit de cache niet leeg. Omdat de URL telkens verschilt (en deze dus nog niet in de cache staat) kan IE niet terugvallen op ge-cachete resultaten en wordt daarmee dus geforceerd een request te versturen naar de server. Dat is iets anders dan "zijn cache leeg gooien"

Dat had ik zo ook gezegd maar dat komt op hetzelfde neer.. het ligt voor de hand dat IE z'n cache niet opruimt wanneer iemand een random getal toevoegt.

[Orwell]

RobIII schreef op woensdag 18 mei 2011 @ 21:51:
[...]

Ik vreest nu juist helemaal
gzip (compressie) en text/html (content-type) heeft namelijk geen drol te maken met caching headers (die, granted, alleen als overeenkomst hebben dat ze ook tussen de andere HTTP headers worden meegestuurd). En dat je van Chrome niet meer zou mogen instellen slaat al helemaal als een tang op een varken

Iets met een klepel die de klok misslaat ofzo

---

edit1:
Dit zijn, bijvoorbeeld, de HTTP headers die ik van GoT terugkrijg voor een bepaalde request:

code:

Cache-Control:private, post-check=1, pre-check=2, max-age=1, must-revalidate
Connection:close
Content-Encoding:gzip
Content-Type:text/html; charset=ISO-8859-15
Date:Wed, 18 May 2011 19:57:00 GMT
Expires:Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified:Wed, 18 May 2011 19:57:00 GMT
P3P:CP="CUR ADM OUR NOR STA NID"
Server:Apache/2.2.17 (Debian) mod_ssl/2.2.17 OpenSSL/1.0.0d
Set-Cookie:LastVisit=1305748620; expires=Fri, 17-Jun-2011 19:57:00 GMT; path=/; domain=.tweakers.net
SessionTime=1305745216; expires=Fri, 17-Jun-2011 19:57:00 GMT; path=/; domain=.tweakers.net
Transfer-Encoding:chunked
Vary:Accept-Encoding

En dat werkt, uiteraard, prima in Chrome. Dus waar je de wijsheid vandaan hebt dat je niet meer mag instellen is mij een raadsel

edit2:

[...]

IE gooit de cache niet leeg. Omdat de URL telkens verschilt (en deze dus nog niet in de cache staat) kan IE niet terugvallen op ge-cachete resultaten en wordt daarmee dus geforceerd een request te versturen naar de server. Dat is iets anders dan "zijn cache leeg gooien"

edit43 :
Oh, en by the way, multi-user-topicstarts (lees: medeauteurs) zijn bedoeld voor het "samen" onderhouden van een topicstart in (bijv. of bijv.) "grote topics"; medeauteurs zijn niet bedoeld om ze ook meteen in 't topic te betrekken; daar kunnen ze zélf een (zinvolle a.u.b.!) post voor in het topic doen of gewoon het topic bookmarken

Ik wil niet lullig doen, maar 95% had je niet hoeven typen/editten.

Wat ik dus probeerde te posten door de edits heen (lol) is dat ik inderdaad de over-de-datum-header bedoelde. Had ik eerder nog niet aan gedacht. Welke dat precies is zoek ik nog wel uit, maar ik begreep in ieder geval wat je zei. En daar ging het om.

Daarom had je dus ook niet het hele verhaal over HTTP-headers hoeven typen. Dat was namelijk al helemaal bekend voor me. Toch bedankt voor de moeite.

Uhm, ohja, Cache-Control.

Orwell wordt een beetje zenuwachtig van multi-ninja-edits

Wow, respect voor uw multitaskskills. Wilde net mede-auteur deleten, maar dat was al gebeurd. Tegelijkertijd met posten en avatar editten. Wonderlijk.

Edit Goed, verder, ik ga inderdaad even naar Expires kijken. Liefst geen random. Kost veels te veel bandbreedte als het aan Google Page Speed ligt (produceert ook random laadtijdspikes). Dank voor de tip voor cache dus.

[Voor 5% gewijzigd door Orwell op 18-05-2011 22:25]

[NMe]

Wie heeft het over random expires gehad? Je zegt wel dat je RobIII begrijpt en dat hij 95% niet had hoeven tikken maar je gzip- en text/html-verhaal enerzijds en nu je vage verhaal over random expires headers anderzijds tonen toch aan dat je iets niet helemaal goed door hebt.Dat is best hoor, maar hou jezelf en ons dan niet voor de gek door te zeggen dat je het allemaal allang weet.

"Random" expires headers kosten niet "extra bandbreedte". Far-future expires headers verlagen de gemiddelde downloadgrootte per request, far past headers vergroten die omdat er niets gecached wordt. Dat maakt niet per definitie far-future headers beter; doorgaans wil je alleen far-future headers op statische content die nooit verandert (icons, header images, enz.) en headers die de cache meteen al invalidaten op content die dynamisch moet zijn, zoals de request die je hier doet. En dan heb je nog wat spul dat daartussenin zweeft, zoals bijvoorbeeld je contentpagina's zelf waar je geen refreshtijd van een week op wil, maar waar je alsnog wél caching voor wil gebruiken.

Anyway, doe jezelf een plezier en lees nog eens even goed na waar je mee bezig bent. Je laat hier vrij duidelijk zien dat dat er ofwel niet goed in zit, ofwel dat het er heel slecht uit komt. Beiden zijn niet echt gunstig voor je.

[Orwell]

Ohkee, hier even wèl de tijd voor nemen. Ik werd dus eerlijk gezegd een beetje gek van de edits en was tegelijkertijd een beetje aan het leren, allemaal niet echt handig voor concentratie.

Goed, ik bedoelde dus dat ik liever niet iets randoms achter de link plak om cachen te voorkomen, maar dat ik Expires wil gebruiken. Toegegeven, niet helemaal helder getypt de vorige keer, maar het stond er toch echt. Niet een random Expires-waarde (wat nergens over gaat). Ook goed te snappen dat als je een Expires van 1000 v Chr. instelt dat je in principe ook cachen voorkomt (als de browser naar de response luistert).

Zoals gezegd schijnen sommige browsers dit te negeren en wordt Cache-Control aanbevolen (met no-cache). Dit zal ik dus direct eens even uit gaan testen.

Ik blijf herhalen, maar vreest niet. Het request/response-verhaal heb ik wel goed op een rijtje.

Uhm, (@Rob) het niet mogen instellen krijg je bijvoorbeeld als je Accept-Encoding, User-Agent en de lengte van de GET-slinger specifiek zelf op wil geven. Als je dat iig vanuit XMLHTTPRequest doet, zeikt Chrome.

En ehm, een Framework of Library zal ik zeker gebruiken als dit voor werk zou zijn, maar zelf wat rondprutsen is juist bedoeld om shite als dit te vatten, en dat vatten is nu net wat je met een library vaak mist.

*Gaat prutsen met headers

[Orwell]

Ohkee, dit is lame.

Het bleek dus dat de drie BOM-bytes van UTF-8 ervoor zorgden dat de PHP-functie 'header()' niet meer werkte. Die werkt namelijk alleen als er nog niks gelezen of getekend is. Daardoor werkte de caching en encoding die ik had ingesteld ook niet. Op de één of andere manier zorgt op de verkeerde plek (na wat bytes dus) header() aanroepen voor het verknoeien van de defaultresponse. En daarom stond Expires en Cache-Control verkeerd.

Wat een feest. Het werkt weer.

[RobIII]

Dan had je een headers already sent blabla error moeten krijgen, of je hebt error reporting uit staan; either way had je het met fatsoenlijk debuggen moeten zien.

Orwell schreef op zaterdag 21 mei 2011 @ 14:39:
Die werkt namelijk alleen als er nog niks gelezen of getekend is. Daardoor werkte de caching en encoding die ik had ingesteld ook niet.

Of er iets "gelezen" (wat je daar onder verstaat weet ik niet) is roest niet. En ik neem aan dat je met "getekend" ge-output bedoeld
Waarom je nu weer caching en encoding in één teug noemt is me ook een raadsel; dat zijn héél verschillende zaken.

[Voor 59% gewijzigd door RobIII op 21-05-2011 17:23]

[Orwell]

RobIII schreef op zaterdag 21 mei 2011 @ 15:48:
Dan had je een headers already sent blabla error moeten krijgen, of je hebt error reporting uit staan; either way had je het met fatsoenlijk debuggen moeten zien.

Heb het net even bekeken, en met bijvoorbeeld USBWebServer én error_reporting(E_ALL) zie ik netjes de fouten op een rijtje, zelfs met een mooi laagje CSS eroverheen. Maar bij deze host(ing2go) niet. Geen enkele ini_set of error_reporting(E_ALL) zorgt voor een foutbericht. Gewoon HTTP 500 (Error dus).

RobIII schreef op zaterdag 21 mei 2011 @ 15:48:
Of er iets "gelezen" (wat je daar onder verstaat weet ik niet) is roest niet. En ik neem aan dat je met "getekend" ge-output bedoeld
Waarom je nu weer caching en encoding in één teug noemt is me ook een raadsel; dat zijn héél verschillende zaken.

Juist, die. Ge-output. Zit een beetje in 3D-jargon te praten. Ben naar namelijk beter bekend mee.

Maar uhm, met dat hele hoopje bedoelde ik dus ook echt de gehele response. Die was gewoon totaal verknoeid. Hier als voorbeeld de Console van Chrome: (BOM, eronder zonder BOM):




Ik was gewoon gezipte content aan het ontvangen zonder dat iemand (de server) het er ooit over gehad heeft in de response. En nu staat er zonder BOM ook gewoon weer de Expires tussen die er altijd al hoorde te staan.

Dus zoals te zien valt was èn caching èn encoding (gzip) kapoet.

[NMe]

Omdat die allebei in je script gezet zijn. Je hebt daarmee de headers gebroken en dat had je kunnen zien door te bepalen dat alle headers die je script had moeten zetten pleite waren. Vervolgens is, als je dat eenmaal opgemerkt hebt, het eerste dat je uitzet de Content-type header omdat je dan de bijbehorende error in beeld krijgt (desnoods met een extra call naar error_reporting() en ini_set() om errors aan te zetten).