04. marts 2009 - 10:17Der er
33 kommentarer og 1 løsning
MSXML / AJAX / IE7 / IIS 7.0 - virker ej
Hej Eksperter!
Jeg er løbet ind i et af de mest underlige problemer jeg har oplevet når det kommer til AJAX og JS generelt.
Jeg har siddet og udviklet en masse funktioner på min localhost, som alle er baseret på AJAX. De virker alle i Internet Explorer 7.0, FireFox 3.0, Safari, Google Chrome, osv. Dvs. koden er god nok - skulle man mene.
Da jeg så uploadede min løsning til en server, ja så stoppede AJAX funktionerne med at virke. Men KUN i IE7 - og endda i selvsamme klient som jeg havde testet med på localhost. :-/
Jeg har brugt hele dagen i går på at søge på nettet på en evt. løsning, men det eneste jeg er kommet nærmere, er at finde ud af HVOR fejlen ca. ligger, og mit umiddelbare gæt er på serveren.
For at I ikke skal sidde og kigge tusindevis af linjer kode igennem, har jeg lavet en simplificeret funktion der ikke gør andet end at sende en GET til en ASP side, som så udskriver den variabel man sender med. Afsendersiden alert'er så responseText'en.
I alt andet end IE7 bliver der alert'et "test" - i IE 7 kommer der en "Handlingen kunne ikke udføres, da der opstod en fejl c00ce56e"
Det er godt nok ud fra PHP, men konklusionen er det samme - det er et tegnkodeproblem. Har du prøvet at skifte den til ISO-8859-1, eller helt fjerne charset-headeren?
Du kunne evt. prøve at implementret det samme med jQuery eller prototype og se om det stadig ikke fungerer. Disse biblioteker har da en vis udbredelse og burde være stabile på de fleste nyere populære platforme. Du kan linke jQuery ind i din side via Googles online scriptbibliotek således:
Ja det har jeg prøvet, der er ingen forskel. Jeg mener at have fundet frem til noget med at det har noget med IIS7.0 at gøre, og den MSXML parser der bruges når det er Internet Explorer, men det virker bare fuldstændigt håbløst, at Microsoft skulle lave noget der ødelægger det for dem selv, eller så måske alligevel ikke, men underligt - ja!
Det skal siges at min oprindelige kode er baseret på jQuery, men fejlen er den samme - dog fik jeg jQuery til at returnere "parseerror".
OK, har du så forsøget at kalde siden med $.ajax i stedet og så sætte parameteren processData:false? Jeg havde selv problemer med at få data tilbage fra serveren på et tidspunkt og der slog jeg automatisk processering af data fra, hvorefter det fungerede. Dog skal jeg ikke kunne sige om det kun fungerede i mit specifikke tilfælde, eller om det er noget der løser problemer med encoding generelt...
Jeg tror grunden til at browseren ikke reagerer på jQuery, er fordi den function der defineres kun kaldes i tilfælde at success og hvis der er parseerror, så vil den kalde error-funktionen i stedet (og den er jo ikke defineret i en $.get).
Der opstod en fejl: parseerror Status: 200 err: undefined
:-O
så vidt jeg ved er status 200 = OK! ... eller hvad?
Jeg har installeret en header sniffer (Wireshark) på opfordring af en anden, men de resultater jeg får fra den siger mig ikke så meget, måske du ville kunne bruge det til noget?
Med forholdsvist komplekse libraries som Prototype og jQuery er det ofte vanskeligt at debugge - og da de er skrevet i gammel, uhensigtsmæssig og invalid kode, kan der ske sære ting.
Prøv et helt simpelt Ajax-eksempel:
<script type="text/JavaScript"> (function(){if(window.XMLHttpRequest)return;var o=null,s,a=["MSXML2.XMLHTTP.6.0", "MSXML2.XMLHTTP.3.0","Msxml2.XMLHTTP","Microsoft.XMLHTTP"];for(var i=0,j=a.length;i<j;s=a[i],i++){try{if(o=new ActiveXObject(s))break}catch(e){}}window.XMLHttpRequest=o?function(){return new ActiveXObject(s)}:null;o=null})();
function askServer(sURL, sQuery) { var _oHttp = new XMLHttpRequest(); _oHttp.open("post", "http://www.domain.dk/page.php", true); _oHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=utf-8"); _oHttp.onreadystatechange = myCallBack; _oHttp.send(sQuery);
function myCallBack() { if (_oHttp.readyState<4) return; alert(_oHttp.responseText); _oHttp = null; } }
Yes... Når jeg har filen åben i eksempelvis Notepad++ står der UTF-8 og jeg er sikker på at jeg har gemt som UTF-8 og at alt bliver encodet i UTF-8 - men er det ikke underligt at det KUN er IE der har problemet? :-/ og vel at mærke KUN når filerne er online, hvis man kører dem på sin egen maskines localhost er der intet problem. Om det så er fordi IIS'en på min egen computer er 5.1 og den på serveren er 7.0, ved jeg ikke, men hvad i al verden skulle der være så anderledes på 7.0'eren at den ikke gider lege med AJAX?
For en god ordens skyld kan jeg sige at det er en Windows Web Server 2008 64 bit, med IIS 7.0 der kører 32-bit kompatibel tilstand.
Det må være et problem på din server. Jeg har aldrig mødt dét problem før - og jeg har ellers lavet en hel del Ajax og rodet med Ajax og lign. teknikker siden 2000
Ja det er også et serverproblem jeg er kommet frem til, men hvem/hvor skal man spørge om specifikt dette problem? :-/ og er der nogen der har en idé om hvad det kunne være på serveren der gør det? Det er jo tilsyneladende kun specifik for folk der bruger IE :-s
Prøv at variere, hvad du skriver i dit asp-dokument. Så kan du måske komme fejlen nærmere. Hvad sker der f.eks, hvis du slet ikke skriver variablen eller andet ud:
Så alert'er den sgu.. :-O men selvfølgelig bare blankt, men for fanden, pardon my french, så er problemet jo nærmere lokaliseret... men hvad dælen så? Er det ASP motoren der udskriver forkerte tegn eller hvad? :-O
Jeg kikker på det i aften engang. Jeg skal hjem nu ;o)
Under PHP har jeg ofte selv haft glæde af at skrive en lille logfil med det indhold/data, jeg ellers prøver at sende retur til browseren (du kan evt. bruge fileSystemObject under ASP). Det er som bekendt ret irriterende, at man ikke direkte kan se sit output, når man roder med Ajax ;o)
Har selv næsten samme problem. Hos mig kan jeg dog få det til at virke ved at trykke på F5 efter den har indlæst siden, men hvis jeg skriver URL'en igen virker det ikke. Jeg tror at olebole er en af de få der kan løse problemet.
":-(" fordi det er utroligt så lidt der skulle til og ":-D" fordi nu virker det jo.
Men hvorfor i al verden ødelægger den ene linje det for IE, men ikke for de andre?
Jeg havde i øvrigt forsøgt at fjerne den linje, men det var i en kæmpe lang fil fyldt med includes, og da det ikke ændrede noget tænkte jeg ikke på at mange af includesne måske også lige har den linje.. :-/
Nå men jeg siger SUUUUUPER mange tak olebole, det var forløsningen på min store knude i hovedet, der har været der i flere uger nu.
Nu skal jeg bare til at søge og erstatte kan jeg se på det hele :-)
Jeg ser frem til en artikel om emnet i fremtiden så ;-)
Tak for hjælpen!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Det er blevet kaldt ”det største it-nedbrud i historien” og omkostningerne kan nemt løbe op i syv milliarder kroner: Men hvem skal betale for Crowdstrikes fejl?
