Her til morgen talte jeg med en Flex arrangement i Hyderabad (Indien). Vores (Savén Technologies) team medlemmer på Hyderabad planlagt og organiseret denne fantastiske begivenhed. Det var en offentlig begivenhed. Over 200 entusiastiske mennesker deltog i arrangementet.
Jeg oprigtigt værdsætter den indsats af arrangørerne og takke deltagerne for at gøre det til et vellykket arrangement.
En af deltagerne spurgte mig et spørgsmål om problemer med Flex HTTPService og IE browser cache. Jeg lovede at give en detaljeret løsning på problemet, så her er det:
Problem: Gentagne HTTPService opkald, når fremstillet af Flex (som kører i en forekomst af IE browser) mange gange ender med ingen ydre HTTP opkald. Det synes data serveres fra cache.
Årsag: Flash Player piggybacks om browseren til at gøre HTTP opkald. IE caches svaret fra HTTP GET opkald og om forekomsten af den samme webadresse returnerer svar fra cache.
Løsning: Problemet kan løses enten på serveren side eller på klientsiden.
Server side løsning: Sæt HTTP headers i svaret for at undgå tilbage svar fra cache.
I HTML: (i overskriften)
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="0">I PHP: (i skrift)
header ("Cache-Control: no-cache, must-forny");
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT");I JSP: (før skriftligt til output stream)
response.setHeader ("Cache-Control", "no-cache");
response.setDateHeader ("Expires", 0);Client side løsning: (1) Foretag HTTP POST opkald - kun HTTP GET opkald serveres fra cache eller (2) Sørg for HTTP GET URL er anderledes hver gang.
(1) gør HTTP POST opkald -
sæt method = "POST" og håndtere opkald korrekt(2) Tilføj et unikt parameter til HTTP GET-opkald, så at webadressen er forskellige hver gang. En unik tidsstempel er et godt valg.
Følgende eksempelkode, kan gøre det job:var timeStampForNocache: Dato = new Date ();
params.noCacheControlVar = timeStampForNocache.getTime (). toString ();
Jeg har navngivet parameter "noCacheControlVar". Du kan navngive det noget andet du vil. Navnet betyder ikke noget. Det afgørende er, at tidsstempel gør HTTP GET URL unik.
Det var det! Håber det hjælper og IE ikke ulejlige Dem, når du bruger HTTPService længere.




























































[...] Kilde [...]
Hej,
Vi har lige stødte på et alvorligt problem i går, hvor vi bruger HTTPService at gøre xmlrpc. Vi gør det via Stillinger bruger as3rpclib (på Google Code) og fundet, at hvis vi forsøger at gøre 2 anmodninger i hurtig rækkefølge de første værker og den anden returnerer en fejl. Brug af Fiddler2 jeg kan se det andet og første anmodninger og begge er faktisk stillinger, og begge returnere korrekte resultater fra serveren.
Når debugging Jeg ser resultatet af den anden indkaldelse til at udløse en # 2032: Stream Fejl.
Har du en idé om noget arbejde arounds i denne sag?
Tak og hilsen
Mark
tak en meget ¡¡¡¡
Jeg havde tilbragt en masse tid på at lede dette ¡¡¡.
Jeg har prøvet det og det virker ¡¡¡
Tak igen.
Hey
Tak for dette indlæg.
Jeg har prøvet det, og jeg arbejdede nobel
Men i dag, mens jeg teste mit projekt, det caches igen ..
noget andet u foreslå at gøre.
Tak Advance
mange tak til stillingen. dette har hjulpet mig nogle timer atleast.
mange tak for POST
Tak en meget, dette netop løser mit problem!
Tak!
Tak mange ..
otra Solucion
http://necmanblog.blogspot.com/2009/04/solucion-al-problema-de-flex-con-el.html
Ændring får lov til at stillinger ikke en acceptabel løsning. De er ikke lige ...
Din server side løsning løste ikke problemet. Her er en meget bedre løsning
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/