ajax en IE

Door Blokker_1999 op woensdag 19 december 2012 10:45 - Reacties (9)
Categorie: /var, Views: 1.904

Voor het werk ben ik met een klein projectje bezig, en voor de eerste keer ben ik een system aan het bouwen dat eens echt gebruik maakt van ajax. Het merendeel van de ontwikkeling heb ik van thuis uit gedaan. Thuis werk ik op Debian met Firefox als webbrowser en alles werkt naar behoren. Ik neem het project mee naar het werk, gooi het op de webserver, tijdens een vergadering vraagt mijn baas om een update, ik wil tonen hoe het werkt maar … er gebeurd niets vanaf er een ajax request aan te pas komt. Het duurt al een tijdje voor ik door heb dat het probleem bij de browser moet liggen aangezien het ook hier wel onder Firefox werkt en ik dus geen oude versie van het project heb meegebracht.

Daar het hier om een simpele POST request ging kon het nu toch echt niet moeilijk zijn. Met behulp van Firebug in Firefox zie ik ook niets dat verkeerd kan zijn dus zoek ik naar een oplossing om het ook eens van uit IE te bekijken. Fiddler is geen optie omdat ik niet aan de proxy instellingen van IE kan en zo kom ik uit bij IEWatch Pro. Geen gratis programma maar wel een 30 dagen trial.

IEWatch toont aan dat de POST correct word gemaakt, maar aan de response zie ik dat deze aan de andere kant niet verwerkt word (php geeft een lege array weer).
http://tweakers.net/ext/f/RpCW1DHpEA5SznZ08y6jlDKK/medium.png
Mijn volgende ingeving is om van POST naar GET om te schakelen. Indien dit correct gebeurd zit alle data netjes in de url en dat kan niet meer misgaan.
http://tweakers.net/ext/f/fvp8Tgnf4tpdd6FYvUo4NpRJ/medium.png
En dat lijkt dus al beter te gaan. Maar nog was mijn probleem niet van de baan. 1 keer ging het goed en daarna niet meer. Lezen we nog wat verder op het internet dan blijkt dit zelfs normaal te zijn. Blijkbaar schrijft de http standaard voor dat een GET request gecached mag worden op elk niveau (browser, proxy, server, …) om de belasting op het netwerk te beperken, en we zien dat ook in de request terugkomen:
http://tweakers.net/ext/f/YJASO4eAm1FnpmALL9eQMQTP/medium.png
De snelste oplossing die ik hiervoor tegenkwam was zorgen dat je url elke keer uniek is. Gewoon een timestamp of random waarde extra bijvoegen.

Blijft de vraag natuurlijk nog waarom mijn POST request faalden. IEWatch geeft aan dat de post data werd meegestuurd terwijl de php file aangeeft dat deze niet ontvangen werd. Ik ga mijn slaap er niet voor laten. Het werkt nu en we kunnen weer verder met een volgend project ;).

Volgende: Valentrein 2013 12-'12 Valentrein 2013
Volgende: update 10-'12 update

Reacties


Door Tweakers user GrooV, woensdag 19 december 2012 10:54

Schrijf acties met een GET doen :X

Door Tweakers user Gtoniser, woensdag 19 december 2012 11:06

Gebruik iets als Fiddler om de requests mee te vergelijken, ik heb nog nooit problemen gehad met POST binnen IE hoewel ik het GET probleem wel ken (wat volledig normaal is trouwens), dus waarschijnlijk zit er toch ergens een fout in je data verwerking.

Door Tweakers user Blokker_1999, woensdag 19 december 2012 11:12

Fiddler kan ik ten vroegste vanavond pas proberen, heb hier geen mogelijkheid om de proxy aan te passen. Er moet inderdaad een verschil zijn of er moet iets niet goed zijn. Het verbaasd me wel dat IEWatch de waarden wel aangeeft als zijnde verstuurd, maar dat de ontvangende file de arrays $_REQUEST en $_POST als leeg weergeeft.

En GrooV, ik weet dat ik hier alles behalve een ellegante oplossing heb neergezet, maar het werkt nu zonder problemen, en dat is het voornaamste. In plaats van nog uren verder te gaan zoeken kan ik me nu op ander werk concentreren.

Door Tweakers user RobIII, woensdag 19 december 2012 11:34

Als je niet aan IE's proxy instellingen kunt betwijfel ik of je wireshark kunt installeren maar die is gratis en zo'n beetje dť tool voor troubleshooten van netwerkproblemen / dit soort zaken.

Als je jQuery (of prototype/mootools/you-name-it) had gebruikt i.p.v. het wiel opnieuw uit te vinden had je dit probleem sowieso niet gehad want die voegen standaard een timestamp of iets dergelijks toe aan een request. Los daarvan is 't gewoon op te lossen door de juiste caching/expiry headers te sturen in de response van de server; dan hoef je ook geen timestamps oid meer mee te sturen. En stiekem is dit probleem al zo oud als Methusalem en al talloze keren besproken op GoT danwel andere plekken op 't web ;)

[Reactie gewijzigd op woensdag 19 december 2012 11:38]


Door Tweakers user Blokker_1999, woensdag 19 december 2012 11:55

tja, maar je moet natuurlijk eerst het probleem identificeren voordat je gericht kan beginnen zoeken, en hoe dichter je bij de oorzaak komt, hoe kleiner de noodzaak om nog te gaan zoeken.

Door Tweakers user crisp, woensdag 19 december 2012 12:15

Voor POST requests moet je waarschijnlijk dit nog toevoegen:

requestObject.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')

Door Tweakers user T i M, woensdag 19 december 2012 12:17

IE heeft een developer console, maar je de headers en content van je requests kunt bekijken. Zit geloof ik onder tools en anders F12 indrukken op de betreffende pagina. Caching kun je disabelen door in je PHP script daarvoor de juiste headers te zetten.

Gebruik je een Javascript framework om de AJAX request te versturen? Zo niet, dan zou ik eens kijken naar Jquery. Scheelt een hoop ellende met cross-browser compatibility.

Door Tweakers user YopY, woensdag 19 december 2012 15:39

RobIII]Als je jQuery (of prototype/mootools/you-name-it) had gebruikt i.p.v. het wiel opnieuw uit te vinden had je dit probleem sowieso niet gehad want die voegen standaard een timestamp of iets dergelijks toe aan een request.
Niet standaard meer tegenwoordig, je zult het zelf aan / uit moeten zetten:


code:
1
$.ajaxSetup({cache:false});


Ik meende ergens te horen dat IE ook POST-request kan gaan cachen, wat ook nog eens in de officiele HTTP standaarden zo beschreven stond - maar ik kan daar zo niet iets van vinden, dus mogelijk is dat BS.

Door Tweakers user Gomez12, donderdag 20 december 2012 14:54

Blokker_1999 schreef op woensdag 19 december 2012 @ 11:12:
En GrooV, ik weet dat ik hier alles behalve een ellegante oplossing heb neergezet, maar het werkt nu zonder problemen, en dat is het voornaamste. In plaats van nog uren verder te gaan zoeken kan ik me nu op ander werk concentreren.
Famous last words...

Elke web-spider die deze url kan vinden (en niet iedereen houdt zich aan de robots.txt standaarden) gaat schrijfacties veroorzaken.

Het zal nu in demo-omgeving vast wel werken. Maar over een halfjaar of een jaar als vanwege reden x/y/z deze pagina gespiderd wordt dan heb je allemaal rare dingen in je db staan en mag iemand weer gaan bughunten en die zal jou daarna waarschijnlijk vervloeken.

Reageren is niet meer mogelijk