AJAX cache probleem

[Verwijderd]

Ik maak voor een webapplicatie gebruik van AJAX voor het zoeken naar personen. Door een aantal letters van een achternaam op te geven kun je snel die persoon vinden die je zoekt. Nu werkt dat voor mij en een hoop andere mensen die de applicatie gebruiken prima, maar voor één persoon niet. Bij deze persoon blijft de PersoonID variabele bewaard. Op alle pagina's waar de zoeker staat wordt standaard die ene patient geselecteerd. Maar eigenlijk mag er geen PersoonID gezet zijn.

Ik heb zelf het vermoeden dat het iets met de instellingen van Internet Explorer te maken heeft, maar ik kan hier niets in ontdekken. Ik plaats het in dit forum omdat ik het vermoeden heb dat het iets met de techniek van AJAX te maken heeft. Mijn vraag is dus: Kan dit probleem (cachen van GET variabelen) te maken hebben met AJAX, en is iemand bekend met de settings van IE om dit te voorkomen.

[BtM909]

Heb je de cache-gegevens al vergelijken (en ook de cache leeggehaald)

Als je gebruikt maakt van get variabelen (die ook elke keer wijzigen ?) dan zou je toch weinig cache hebben?

[Verwijderd]

Het rare is dat ik mijn cache zelf gewoon aan heb staan. Ik cache wel tot 1000mb en ik heb nergens last van. Ik bedoel dus niet de standaard cache instellingen van IE, maar een ander soort instelling die ik dus niet kan ontdekken.

[BtM909]

Verwijderd schreef op woensdag 17 mei 2006 @ 11:51:
Het rare is dat ik mijn cache zelf gewoon aan heb staan. Ik cache wel tot 1000mb en ik heb nergens last van. Ik bedoel dus niet de standaard cache instellingen van IE, maar een ander soort instelling die ik dus niet kan ontdekken.

Ik heb het over de cache-instellingen (van IE). Welke browser test je het mee?

[DPLuS]

Ik had hetzelfde probleem onder IE als ik van het XMLHTTP object een bestand met dezelfde naam terugkreeg.

De oplossing voor mij luidde (voor GET en POSTS van het xmlhttp object):

JavaScript:

    if (navigator.appName == "Microsoft Internet Explorer")
        this.commInterface.setRequestHeader("If-Modified-Since", "Wed, 15 Nov 1995 04:58:08 GMT")

HTH

[ Voor 14% gewijzigd door DPLuS op 17-05-2006 16:51 ]

[soulrider]

Ik weet niet hoe ver het zit met ev. proxy's ertussen,
maar mogelijk is dat oo kde reden, een cachede proxy-server ?

(en dan kan het ev. wel opgelost worden met de hierboven vermelde opl.)

[quexy]

Ik heb ook een keer problemen gehad met de cache van IE met ajax. IE wilde hierbij maar 1x de desbetreffende url openen, om vervolgens de resultaten uit cache te gebruiken. Wat mij opviel is dat dit bij Mozilla wel goed werkte.

De oplossing in mijn geval was de url elke keer iets te veranderen door unieke data toe te voegen in de querystring (bijvoorbeeld de tijd)

[T-MOB]

Volgens de rfc horen GET requests ook veilig gecached te kunnen worden. Ze zijn bedoeld voor data die in principe bij elk request hetzelfde is. Zodra je serverside actie onderneemt op het request dan hoor je POST te gebruiken. Aan die informatie heb je nu waarschijnlijk weinig, maar voor een volgende keer...
De oplossing ligt nu in een work-around in de vorm van cache-headers (die alsnog genegeerd kunnen worden door een browser), of de oplossing van quexy die zeker goed zal gaan.

[Erkens]

T-MOB schreef op donderdag 18 mei 2006 @ 00:29:
Volgens de rfc horen GET requests ook veilig gecached te kunnen worden. Ze zijn bedoeld voor data die in principe bij elk request hetzelfde is. Zodra je serverside actie onderneemt op het request dan hoor je POST te gebruiken.

Hij vraagt dus ook gegevens op met GET zoals het hoort

Daarnaast vertellen de expire headers tot wanneer de verkregen data geldig is. Want als je het zo bot zegt zoals jij dat hier doet, dan zal bijna elke request die je ergens doet een POST moeten zijn aangezien je anders weinig dynamiek zal krijgen

[Cloud]

quexy schreef op donderdag 18 mei 2006 @ 00:11:
De oplossing in mijn geval was de url elke keer iets te veranderen door unieke data toe te voegen in de querystring (bijvoorbeeld de tijd)

Dit is eigenlijk de meest gebruikte methode om dit probleem te verhelpen. De laatste tijd zie je het zelfs in de examples voorkomen:

JavaScript:

var url="getQuery.php?sid=" + Math.random() + "&rid=" + str;

[crisp]

Random strings in je URL query-string is een lapmiddel; dit is gewoon met HTTP headers op te lossen.
Serverside kan je idd expire headers geven, maar nog belangrijker: cache-control headers

[Cloud]

crisp schreef op donderdag 18 mei 2006 @ 00:38:
Random strings in je URL query-string is een lapmiddel; dit is gewoon met HTTP headers op te lossen.
Serverside kan je idd expire headers geven, maar nog belangrijker: cache-control headers

Met meest gebruikte bedoelde ik niet de beste Maar inderdaad het is wel een lapmiddel ja. Headers zouden beter zijn, al weet je van random-urls dat ze sowieso werken (lees: lekker snel te implementeren)

Kortom, genoeg oplossingen voor dit probleem!

Ookal zijn cache-control headers eigenlijk net zo snel toe te voegen bedenk ik me nu.

[Verwijderd]

wolkje schreef op donderdag 18 mei 2006 @ 00:47:
al weet je van random-urls dat ze sowieso werken (lees: lekker snel te implementeren)

Dat is dus het leuke van random, je zou zo maar twee keer achter elkaar dezelfde waarde kunnen krijgen Als je het dan al oplost met zo'n smerige workaround, doe het dan met de eerder genoemde tijd als request attribute.

[T-MOB]

Erkens schreef op donderdag 18 mei 2006 @ 00:32:
[...]
Hij vraagt dus ook gegevens op met GET zoals het hoort

Maar als dat zo is dan kun je toch niet gelijk bij de uitkomst eindigen? Een GET request *hoort* in principe elke keer dezelfde gegevens op te leveren bij hetzelfde request. (Behoudens de gevallen waarin de content een update heeft gehad, waarvoor caching/expire headers bestaan). Het enige cachingprobleem dat je zou kunnen hebben bij correct gebruik van GET requests is dat je in je client-applicatie werkt met de verouderde gecachedte data.

Daarnaast vertellen de expire headers tot wanneer de verkregen data geldig is. Want als je het zo bot zegt zoals jij dat hier doet, dan zal bijna elke request die je ergens doet een POST moeten zijn aangezien je anders weinig dynamiek zal krijgen

Allicht drukte ik me niet zo handig uit, maar ik doelde met "serverside actie" natuurlijk niet op de acties die nodig zijn om de content op te halen/te serveren. Het gaat om acties waarbij er aan de serverside iets wordt opgeslagen / veranderd.

In geval van een autocomplete voor een naam stel ik me zo voor dat je bij een onchange van het naamveld een request doet in de vorm GET autoComplete?type=name&str=strNaamveld. Een cacheprobleem kan dan alleen bestaan uit aan lokaal werken met verouderde data.
TS doet echter blijkbaar wat anders waarbij er op de server tussenstappen worden bewaard (anders kom je immers niet gelijk op het gecachedte result). Zijn GET request wijst dus niet naar data die in principe altijd hetzelfde is, maar naar data die afhankelijk is van voorgaande requests / een bepaalde staat op de server. In zulke gevallen hoor je POST te gebruiken...

[Erkens]

T-MOB schreef op donderdag 18 mei 2006 @ 10:40:
In geval van een autocomplete voor een naam stel ik me zo voor dat je bij een onchange van het naamveld een request doet in de vorm GET autoComplete?type=name&str=strNaamveld. Een cacheprobleem kan dan alleen bestaan uit aan lokaal werken met verouderde data.
TS doet echter blijkbaar wat anders waarbij er op de server tussenstappen worden bewaard (anders kom je immers niet gelijk op het gecachedte result). Zijn GET request wijst dus niet naar data die in principe altijd hetzelfde is, maar naar data die afhankelijk is van voorgaande requests / een bepaalde staat op de server. In zulke gevallen hoor je POST te gebruiken...

Nee, POST hoor je alleen te gebruiken als je de gegevens wilt veranderen op de server, iets waar hier absoluut geen sprake van is, je wilt gegevens ophalen en of daarbij eventuele queries van vorige requests gecached worden op de server maakt daar geen verandering in. GET is hierbij de juiste methode.

[Cloud]

Verwijderd schreef op donderdag 18 mei 2006 @ 09:23:
[...]

Dat is dus het leuke van random, je zou zo maar twee keer achter elkaar dezelfde waarde kunnen krijgen Als je het dan al oplost met zo'n smerige workaround, doe het dan met de eerder genoemde tijd als request attribute.

Tja dat klopt Ik had het eigenlijk niet als zijnde echt 'random' urls bedoeld, maar bedoelde meer de workaround om het op te lossen (dus random, of tijd, of etc.). Maar tijd is nog weer een stukje veiliger, dat zeker.