🚀 go-pugleaf

W dniu 2012-11-12 12:02, jaro pisze:
> Za pomocą XMLHttpRequest wysyłam cyklicznie (co 1 sekundę) zapytanie
> zwracające bieżący czas. Wszystko działa poprawnie do czasu.
> Odpowiedzi przychodzą z serwera średnio po 70ms jednak stopniowo te
> czasy rosną. Odpowiedzi pojawiają się po 150, 300, 500ms a po
> dłuższym czasie nawet występuje opóźnienie rzędu kilku, kilkunastu
> sekund. Jaka może być tego przyczyna?

Moze serwer jest tak ustawiony, ze tylko pozwala na określoną ilość
połączeń w określonym czasie. Sprawdź to.

-- 
Cezary Tomczyk
http://www.jscode.info/

Może nieprecyzyjnie się wyraziłem. Po pewnym okresie te dłuższe czasy zaczynają się pojawiać (stopniowo coraz częściej i coraz dłuższe) jednak nadal większość odpowiedzi przychodzi ze średnim czasem opóźnienia +/- 70ms. Nie jest tak, że są tylko te dłuższe.

W dniu 2012-11-12 15:31, jaro pisze:
> Może nieprecyzyjnie się wyraziłem. Po pewnym okresie te dłuższe czasy
> zaczynają się pojawiać (stopniowo coraz częściej i coraz dłuższe)
> jednak nadal większość odpowiedzi przychodzi ze średnim czasem
> opóźnienia +/- 70ms. Nie jest tak, że są tylko te dłuższe.

Może to być jeszcze kwestia tego, że za dużo jest na raz połączeń i 
przeglądarka zwyczajnie blokuje je po określonym limicie. Zależy to od 
przeglądarki, ale generalnie waha się to od 2-10 na raz. Więc, jak limit 
przekroczyłeś, to przeglądarka wstrzymuje request-y do czasu, aż jakiś 
się skończy. Tworzy się tzw. kolejka.

Patrz lista z limitami wg przeglądarki:
http://stackoverflow.com/a/985704/896702

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

W dniu poniedziałek, 12 listopada 2012 21:06:26 UTC+1 użytkownik Cezary Tomczyk napisał:
> W dniu 2012-11-12 15:31, jaro pisze:
> 
> > Mo�e nieprecyzyjnie si� wyrazi�em. Po pewnym okresie te d�u�sze czasy
> 
> > zaczynaj� si� pojawia� (stopniowo coraz cz�ciej i coraz d�u�sze)
> 
> > jednak nadal wi�kszo�� odpowiedzi przychodzi ze �rednim czasem
> 
> > op�nienia +/- 70ms. Nie jest tak, �e s� tylko te d�u�sze.
> 
> 
> 
> Mo�e to by� jeszcze kwestia tego, �e za du�o jest na raz po��cze� i 
> 
> przegl�darka zwyczajnie blokuje je po okre�lonym limicie. Zale�y to od 
> 
> przegl�darki, ale generalnie waha si� to od 2-10 na raz. Wi�c, jak limit 
> 
> przekroczy�e�, to przegl�darka wstrzymuje request-y do czasu, a� jaki� 
> 
> si� sko�czy. Tworzy si� tzw. kolejka.
> 
> 
> 
> Patrz lista z limitami wg przegl�darki:
> 
> http://stackoverflow.com/a/985704/896702
> 
> 
> 
> -- 
> 
> Cezary Tomczyk
> 
> http://www.ctomczyk.pl/

Tylko te limity dotyczą równoległych zapytań. Skoro czas odpowiedzi to średnio 70ms to przed utworzeniem następnego (po 1 sek) poprzednie powinno się zakończyć. Jeśli się nie zakończyło i utworzy się równolegle kolejne to wracamy do punktu wyjścia - skąd powstało opóźnienie pierwszego?

W dniu 2012-11-12 22:02, jaro pisze:
> Tylko te limity dotyczą równoległych zapytań. Skoro czas odpowiedzi
> to średnio 70ms to przed utworzeniem następnego (po 1 sek) poprzednie
> powinno się zakończyć. Jeśli się nie zakończyło i utworzy się
> równolegle kolejne to wracamy do punktu wyjścia - skąd powstało
> opóźnienie pierwszego?

[1] Czy wywołujesz request XHR jeden po drugim, ale czekając, aż 
poprzedni się skończy?
[2] Czy też wywołujesz je po prostu każdy po kolei nie czekając aż 
poprzedni się zakończy?

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

> [1] Czy wywo�ujesz request XHR jeden po drugim, ale czekaj�c, a� 
> 
> poprzedni si� sko�czy?
> 
> [2] Czy te� wywo�ujesz je po prostu ka�dy po kolei nie czekaj�c a� 
> 
> poprzedni si� zako�czy?

Wywołuję poprzez xmlhttp.open("GET","xxx.php"+"?ssid="+Math.random(),true); czyli asynchronicznie

W dniu 2012-11-13 23:53, jaro pisze:
>> [1] Czy wywo�ujesz request XHR jeden po drugim, ale czekaj�c, a�
>>
>> poprzedni si� sko�czy?
>>
>> [2] Czy te� wywo�ujesz je po prostu ka�dy po kolei nie czekaj�c a�
>>
>> poprzedni si� zako�czy?
>
> Wywołuję poprzez xmlhttp.open("GET","xxx.php"+"?ssid="+Math.random(),true); czyli asynchronicznie

No to nie dziw się, że jeśli wywołujesz kilka(naście/dziesiąt/set) żądań 
HTTP w bardzo krótkim czasie, zaczyna Ci się wszystko spowalniać. Serwer 
musi "przetrawić" żądania http, a im jest ich więcej, tym kolejka się 
wydłuża.

Spróbuj je wysyłać synchronicznie - nie wysyłaj żądania póki poprzednie 
się nie skończy. Wówczas będziesz miał do czegoś się odnieść. Teraz to 
trochę wróżenie z fusów.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

W dniu 13.11.2012 23:53, jaro pisze:
>> [1] Czy wywo�ujesz request XHR jeden po drugim, ale czekaj�c, a�
>> poprzedni si� sko�czy?
>> [2] Czy te� wywo�ujesz je po prostu ka�dy po kolei nie czekaj�c a�
>> poprzedni si� zako�czy?
> Wywołuję poprzez xmlhttp.open("GET","xxx.php"+"?ssid="+Math.random(),true); czyli asynchronicznie

A mierzyłeś czas przetwarzania po stronie serwera? Zawsze jest krótki?
-- 
td

> No to nie dziw się, że jeśli wywołujesz kilka(naście/dziesiąt/set) żądań 
> 
> HTTP w bardzo krótkim czasie, zaczyna Ci się wszystko spowalniać. Serwer 
> 
> musi "przetrawić" żądania http, a im jest ich więcej, tym kolejka się 
> 
> wydłuża.
> 
> 
> 
> Spróbuj je wysyłać synchronicznie - nie wysyłaj żądania póki poprzednie 
> 
> się nie skończy. Wówczas będziesz miał do czegoś się odnieść. Teraz to 
> 
> trochę wróżenie z fusów.
> 

No nie przesadzajmy. Jeśli zapytanie do serwera raz na sekundę miałoby go zatykać to nie byłby to serwer tylko jakiś składak pod biurkiem. Zasoby serwera są wystarczające a nawet za duże (wykorzystanie procesora na poziomie do 5%, pamięci do 15%). Poza tym skoro odpowiedzi przychodzą po 70ms (średnio) nie ma na co czekać. Zresztą sprawdziłem jak się zachowuje przy zapytaniach synchronicznych i różnicy nie było.

> 
> A mierzyłeś czas przetwarzania po stronie serwera? Zawsze jest krótki?
> 

Tak, mierzyłem. Czas wygenerowania odpowiedzi na serwerze jest rzędu kilku ms. To jest może kilka linijek kodu (pobranie godziny, przygotowanie nagłówka). Jak miałem odpowiedź generowaną na podstawie danych w bazie (parę rzeczy się tam robiło) czas generowania wzrastał do 10ms

Użytkownik "jaro" <jarek.lipiny@gmail.com> napisał w wiadomości
news:34127733-0f56-4d5a-98ac-a4c369cabc72@googlegroups.com...
> Za pomocą XMLHttpRequest wysyłam cyklicznie (co 1 sekundę) zapytanie
> zwracające bieżący czas. Wszystko działa poprawnie do czasu. Odpowiedzi

A po co? czy 10 sekund, a nawet minuta na serwerze, az tak roznie plynie, co 
na kliencie?

> przychodzą z serwera średnio po 70ms jednak stopniowo te czasy rosną.
> Odpowiedzi pojawiają się po 150, 300, 500ms a po dłuższym czasie nawet
> występuje opóźnienie rzędu kilku, kilkunastu sekund.
> Jaka może być tego przyczyna?

.setInterval zamiast .setTimeout ?

Co nie zmienia faktu, ze nie ma sensu co sekunde uzgadniac czasu.

sz. 

> 
> A po co? czy 10 sekund, a nawet minuta na serwerze, az tak roznie plynie, co 
> na kliencie?
> 
W rzeczywistym przykładzie nie chodzi o czas. Chodzi o jak najbardziej bieżące informacje pobierane z serwera, które mogą być modyfikowane przez innych użytkowników. 
> 
> .setInterval zamiast .setTimeout ?
> 
W jednym i drugim przypadku jest tak samo. 
> 
> Co nie zmienia faktu, ze nie ma sensu co sekunde uzgadniac czasu.
> 
Jak wyżej - nie uzgadniam czasu. Przedstawiam użytkownikowi bieżący stan danych na serwerze, które są równolegle modyfikowane przez innych użytkowników.

Próbowałem też wycinać zapytania na które przez dłuższy czas nie przychodzi odpowiedź za pomocą timeout i ontimeout obiektu XMLHttpRequest ale w Chrome to nie działa. Tak jakby to zdarzenie nie było w Chrome obsługiwane (w IE o dziwo działa).

Użytkownik "jaro" <jarek.lipiny@gmail.com> napisał w wiadomości
news:6473795f-5479-4f02-b07e-5a712fba017d@googlegroups.com...

> Jak wyżej - nie uzgadniam czasu. Przedstawiam użytkownikowi bieżący stan
> danych na serwerze, które są równolegle modyfikowane przez innych
> użytkowników.

HTTP do takich wynalazkow jest takim sobie pomyslem :/

> Próbowałem też wycinać zapytania na które przez dłuższy czas nie
> przychodzi odpowiedź za pomocą timeout i ontimeout obiektu XMLHttpRequest
> ale w Chrome to nie działa. Tak jakby to zdarzenie nie było w Chrome
> obsługiwane (w IE o dziwo działa).

Nie zostaja Ci HpptRequesty w powietrzu?
Jakies roznice miedzy synchronicznym/asynchronicznym trybem requesta?
Probowales pobierac te dane przez dynamiczne dodawanie elementu script?
Jestes pewien, ze problem nie jest po stronie serwera?

sz. 

> HTTP do takich wynalazkow jest takim sobie pomyslem :/ 

A co by było dobrym pomysłem?

> Nie zostaja Ci HpptRequesty w powietrzu? 

Chrome radzi sobie z tym lepiej. IE8 gorzej. Ilość równoległych zapytań w każdej przeglądarce jest inna. Ale zapytania na które nie przychodzi odpowiedź w IE8 wycinam za pomocą metody abort(). W Chrome to nie działa. Mechanizm timeout nie działa.

> Jakies roznice miedzy synchronicznym/asynchronicznym trybem requesta? 

Różnicy nie ma. Robię i jedno i drugie i jest tak samo.

> Probowales pobierac te dane przez dynamiczne dodawanie elementu script? 

Co masz na myśli?

> Jestes pewien, ze problem nie jest po stronie serwera? 

Serwer nie jest problemem. Wydajność jest wystarczająca a nawet na wyrost.

Z jakich mechanizmów korzysta np oprogramowanie sesji na giełdzie? Tam czas na złożenie oferty jest krótki i informacja dla innych musi być natychmiast widoczna.

jaro <jarek.lipiny@gmail.com> napisał(a)
>
>> Jestes pewien, ze problem nie jest po stronie serwera? 
>
> Serwer nie jest problemem. Wydajność jest wystarczająca a nawet na wyrost.
>

A nie ma tam (na serwerze) jakichś firewalli, fail2ban, mod_throtle, czy
innych wynalazków, które mogłyby banować, wielokrotne łączenie się z
tego samego ip?

-- 
Tomek 

> A nie ma tam (na serwerze) jakichś firewalli, fail2ban, mod_throtle, czy
> innych wynalazków, które mogłyby banować, wielokrotne łączenie się z
> tego samego ip?
> 
Nie nie ma.

Użytkownik "jaro" <jarek.lipiny@gmail.com> napisał w wiadomości
news:80060841-ecc9-42d5-ae4d-8ab6dfc7fd32@googlegroups.com...

> A co by było dobrym pomysłem?

Dobrym - nic. HTTP jest HTTP.

>> Probowales pobierac te dane przez dynamiczne dodawanie elementu script?

To moze byc mniej zlym rozwiazaniem.

> Serwer nie jest problemem. Wydajność jest wystarczająca a nawet na wyrost.

Sie upewnij sie. To, ze wydajnosc jest na wyrost nie oznacza, ze nie zmuli.

sz. 

W dniu wtorek, 13 listopada 2012 23:53:26 UTC+1 użytkownik jaro napisał:
> > [1] Czy wywo�ujesz request XHR jeden po drugim, ale czekaj�c, a� 
> 

> 
> Wywołuję poprzez xmlhttp.open("GET","xxx.php"+"?ssid="+Math.random(),true);
> czyli asynchronicznie

Moze jak zajrzysz do kesza to będziesz miał odpoowiedź.

Prawdopodobnie ten random wali ci niezliczoną ilość plików
w keszu co wydłuża szukanie ostatniego pliku,
ja bym zrobił tak: ...GET","xxx.php"+"?" to spowoduje,
że masz jeden plik wymiany w keszu, w którym aktualizowana
jest treść. Również jak serwer umożliwia tryb POST dla ajaksa
to wszystko działa jak ta lala.

W PHP należy dać takie hidery:
<?php
//Set no caching
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); 
header("Cache-Control: no-store, no-cache, must-revalidate"); 
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
?> 

a w html:
<meta http-equiv="cache-control" content="no-cache">

Niestety coś w przeglądarkach pogmatawali i moje
dawne aplikacje ajaksowe przestały prawidłowo działać
musiałem poprzerabiać wszystko na refresze (chodzi jedną nazwę
pliku wymiany). Gorsze to ale niezawodne.

Andrzej.

> Moze jak zajrzysz do kesza to będziesz miał odpoowiedź.
> Prawdopodobnie ten random wali ci niezliczoną ilość plików
> w keszu co wydłuża szukanie ostatniego pliku,

Fakt, trochę tego jest :(

> ja bym zrobił tak: ...GET","xxx.php"+"?" to spowoduje,
> że masz jeden plik wymiany w keszu, w którym aktualizowana
> jest treść. 

Sprawdzę to

> Również jak serwer umożliwia tryb POST dla ajaksa
> to wszystko działa jak ta lala.

Przez POST już robiłem i nie było różnicy

> W PHP należy dać takie hidery:
> <?php
> //Set no caching
> header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
> header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); 
> header("Cache-Control: no-store, no-cache, must-revalidate"); 
> header("Cache-Control: post-check=0, pre-check=0", false);
> header("Pragma: no-cache");
> ?> 
> a w html:
> <meta http-equiv="cache-control" content="no-cache">

To już miałem

> Niestety coś w przeglądarkach pogmatawali i moje
> dawne aplikacje ajaksowe przestały prawidłowo działać
> musiałem poprzerabiać wszystko na refresze (chodzi jedną nazwę
> pliku wymiany). Gorsze to ale niezawodne.

A to jest ciekawe. U mnie ta sama aplikacja też wcześniej działała bez problemów. Przerobienie na refresh raczej mi nie pasuje. Na stronie oprócz wyświetlanych danych jest formularz. Przy odświeżaniu co 1 sek nie dało by się nic wpisać. Trzeba by dzielić na ramki. Poza tym efekt migania powodowałby ból głowy. Ciekawe co mogło się zmienić w przeglądarkach co powoduje teraz problemy?
A wracając do tematu, Chrome i FF radzą sobie z tym problemem dłuższych czasów a niestety IE nie (wersja 8 i 9). Ostatnio zaobserwowałem tak jakby puste zapytania. Tworzone jest zapytanie ale bez żadnych nagłówków. IE to pokazuje pod F12 i wywala się na obsłudze odpowiedzi.

> ja bym zrobił tak: ...GET","xxx.php"+"?" to spowoduje,
> że masz jeden plik wymiany w keszu, w którym aktualizowana
> jest treść. 

No i sprawdziłem. W takiej wersji IE9 zgłasza kod odpowiedzi 304 - brak modyfikacji - czyli nie pobiera nowych wartości z serwera.
W Chrome działa.

W dniu piątek, 7 grudnia 2012 00:04:06 UTC+1 użytkownik jaro napisał:
> > ja bym zrobił tak: ...GET","xxx.php"+"?" to spowoduje,
> 
> > że masz jeden plik wymiany w keszu, w którym aktualizowana
> 
> > jest treść. 
> 
> 
> 
> No i sprawdziłem. W takiej wersji IE9 zgłasza kod odpowiedzi 304 - brak modyfikacji - czyli nie pobiera nowych wartości z serwera.
> 
> W Chrome działa.



Teraz dopiero zauważyłem, że zapomniałem o nazwie pliku
czyli tak: ...GET","xxx.php"+"?myplik.txt". Sory.


No właśnie a moi klienci wykorzystują wyłacznie IE, bo korzystam
jeszcze z innych mało znanych funkcji tej przegladarki.

Nie wiem czy sie przyda ale przytocze z neta dyskusję na te tematy:

----------------------------------

Przydatnym narzędziem do sprawdzania nagłówków jest plugin WebDeveloper dla Firefoxa / Mozilli. 
Jest tylko jeden mankament - nigdy nie pokazuje nagłówków 304 Not Modified - zawsze pokazuje 
ostatnie 200 OK - przydałby się bardziej sniffer typu tcpdump, ethereal.
 
Jak się zachowują przeglądarki.
 
Firefox przy każdym odwołaniu do keszowanego dokumentu będzie wysyłał do serwera request 
i dostawał 304 aż dokument zostanie zmieniony.

IE przy każdym odwołaniu do keszowanego dokumentu będzie pobierał go z dysku 
aż do upłynięcia max-cache sekund. 
Wtedy połączy się z serwerem i dostanie 304.
Oczywiście jeżeli dokument zostanie usunięty z kesza przeglądarki będzie musiała się 
ona połączyć i pobrać go w całości.
 
Jest pewien konflikt pomiędzy IE a mod_deflate apacza:
 1.IE po wymuszeniu przez F5/Ctrl-F5 łaskawie pobierze z serwera nowszą wersję dokumentu
 2.przy ponownym wejściu na ten dokument ładuje poprzednią (starą) wersję - z dysku !!!
 3.wydaje mi sie, że taka ciuciubabka trwa aż do upłynięcia max-cache czasu. 
   Wtedy IE łączy się z serwerem i dostaje nową stronę.

 
Oprócz dokumentów generowanych przez PHP można zatrudnić apacza do ustawiania odpowiednich 
nagłówków - odpowiada za to moduł expires:

LoadModule expires_module lib/apache/mod_expires.so
<IfModule expires_module>
 ExpiresActive On#ExpiresDefault "access plus 1 days"#ExpiresByType text/html "access plus 1 minutes"ExpiresByType image/gif "access plus 3 days"ExpiresByType image/png "access plus 3 days"ExpiresByType image/jpeg "access plus 3 days"ExpiresByType application/x-javascript "access plus 3 days"ExpiresByType text/css "access plus 3 days"
</IfModule>

Użyte tutaj ExpiresByType mówi apaczowi aby dodawał nagłówki keszujące do obrazków, 
plików .js i .css, można do tego dodać na przykład .pdf, .zip, .doc. 
Gdyby ExpiresDefault był odhaszowany toby wszystkie dokumenty serwowane przez apacza 
były keszowane przez 1 dzień - dla mnie jako programisty PHP to nieprzydatna właściwość.
 

----------------------------------


Andrzej.

On 2012.12.04 01:44, jaro wrote:

>> HTTP do takich wynalazkow jest takim sobie pomyslem :/ 
> 
> A co by było dobrym pomysłem?

http://en.wikipedia.org/wiki/WebSocket
Ale nie wszystkie browsery mają to zaimplementowane jeszcze.


-- 
Tomek

W dniu sobota, 8 grudnia 2012 15:29:52 UTC+1 użytkownik Tomasz Sowa napisał:
> http://en.wikipedia.org/wiki/WebSocket
> Ale nie wszystkie browsery majďż˝ to zaimplementowane jeszcze.
> 
No właśnie. Z tego powodu odpada.

Krótkie podsumowanie:
- za każdym razem tworzę nowy obiekt XMLHttpReqest - wykorzystanie jednego globalnego powoduje problemy. Każda przeglądarka może wysłać równolegle kilka zapytań. Jak się ta pula wyczerpie to obiekt jest nadpisywany i wszystko pada.
- za pomocą xmlhttp.ontimeout wychwytuję zapytania na które nie przyszła odpowiedź w określonym czasie. 'Zabijam' je za pomocą xmlhttp.abort(). Chrome nie obsługuje tego wcale a IE z problemami - po ubiciu zapytania  IE zgłasza xmlhttp.readyState=4 z 'pustym' obiektem - obsługuje wyjątkami.
- tworzę zapytanie bez użycia Math.random() w celu pominięcia cacha przeglądarki. Stosuję tylko odpowiednie nagłówki http. Użycie unikatowego linku powoduje nadmierne zapełnienie cacha przeglądarki kolejnymi wersjami plików.
- po tych wszystkich zabiegach w Chrome raczej działa poprawnie, w IE9 blisko poprawności a w IE8 co pewien czas wywala przeglądarkę.

Chyba się zastrzelę ;)

W dniu 2012-12-14 13:46, jaro pisze:
> Krótkie podsumowanie: - za każdym razem tworzę nowy obiekt
> XMLHttpReqest - wykorzystanie jednego globalnego powoduje problemy.
> Każda przeglądarka może wysłać równolegle kilka zapytań. Jak się ta
> pula wyczerpie to obiekt jest nadpisywany i wszystko pada. - za

Niekoniecznie musisz za każdym razem tworzyć nową instancję 
XMLHttpRequest. Sprawdź, czy poprzednia jeszcze istnieje  i jeśli ma 
readyState === 4 to możesz ponownie użyć tej samej instancji.

> pomocą xmlhttp.ontimeout wychwytuję zapytania na które nie przyszła
> odpowiedź w określonym czasie. 'Zabijam' je za pomocą
> xmlhttp.abort(). Chrome nie obsługuje tego wcale a IE z problemami -
> po ubiciu zapytania  IE zgłasza xmlhttp.readyState=4 z 'pustym'
> obiektem - obsługuje wyjątkami. - tworzę zapytanie bez użycia

IE słabo lub wcale nie radzi sobie z obsługą np. requestów do nie 
istniejących zasobów (i podobnych problemów). Ja robię tak:

1. Ustawiam var done = false; zaraz po metodzie send().
2. Ustawiam setTimeout na 30 sekund i po tym wywołuję lokalną metodę 
_abort w której sprawdzam, czy "done" jest false / true. Jeśli false to 
robię abort().
3. W przypadku, gdy request powiódł się, to "done" ustawiam na true i 
kasuję timeOut-a.

> Math.random() w celu pominięcia cacha przeglądarki. Stosuję tylko
> odpowiednie nagłówki http. Użycie unikatowego linku powoduje
> nadmierne zapełnienie cacha przeglądarki kolejnymi wersjami plików. -

MZ lepiej robić sobie build-y nowe do nowych katalogów za każdym razem, np.

/build123/[...]
/build124/[...]

Wówczas masz gwarancję, że klient zawsze pobierze najnowsze pliki i 
jeśli nic się nie zmieni to przy ponownym wejściu będą pobierane z cache 
przeglądarki. W uproszczeniu.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

W dniu piątek, 14 grudnia 2012 22:33:38 UTC+1 użytkownik Cezary Tomczyk napisał:
> W dniu 2012-12-14 13:46, jaro pisze:
> 
> 1. Ustawiam var done = false; zaraz po metodzie send().
> 2. Ustawiam setTimeout na 30 sekund i po tym wywołuję lokalną metodę 
> _abort w której sprawdzam, czy "done" jest false / true. Jeśli false to 
> robię abort().
> 3. W przypadku, gdy request powiódł się, to "done" ustawiam na true i 
> kasuję timeOut-a.

Tak zrobiłem ale zmian nie ma.

Poprawna sekwencja zdarzeń jest następująca: tworzę obiekt XMLHttpRequest, readyState=1, send, readyState=2, readyState=3, readyState=4, obsługa odpowiedzi.
W IE9 wygląda to tak: tworzę obiekt XMLHttpRequest, readyState=1, readyState=1 send, readyState=2, readyState=3, readyState=4, obsługa odpowiedzi - dwa razy zgłasza się readyState=1.
A czasami w IE9 wygląda to tak: tworzę obiekt XMLHttpRequest, readyState=1, readyState=1 send, readyState=4, tu brakuje odpowiedzi i tu jest dłuższy czas który kasuje przez abort().
W tym ostatnim przykładzie w narzędziach deweloperskich IE9 w podglądzie zapytania brakuje nagłówków zapytania, i w związku z tym odpowiedzi. Wszystko jest puste.

Może troche off topic ale co się mi rzuca w oczy to to że ta obsługa  XMLHttpRequest jest raczej "niskopoziomowa". Czy nie lepiej używać jakiegoś przenośnego ( między przeglądarkami ) wraper -a na XMLHttpRequest np. jQuery.ajax  ?