[javascript] opvangen 'opvraagfalen' httprequest

[Verwijderd]

Het probleem zit als volgt, ik werk momenteel aan een user-passwoord systeem waar aan de hand van een url á la pagina.htm?user=test&pass=test1, waar de reeds versleutelde inhoud van test.xml aan de hand van het wachtwoord test1 gedecodeerd wordt en in een div geplaatst wordt.

Nu, dit is allemaal geen probleem als het xml-bestand bestaat [wachtwoord verkeerd = onleesbare data]. Maar als het xml-bestand niet bestaat, dan krijg ik een lelijke error. Terwijl ik dit juist zoveel mogelijk tracht te vermijden [ik vermijd stricte js-fouten en ff/ie/opera incompatibiliteit].

Dus mijn vraag naar julie is: hoe vang ik op een nette manier een niet-bestaande httprequest op ?

Dit is de desbetreffende code:

JavaScript:

   xmlObj.onreadystatechange = function(){
    if(xmlObj.readyState == 4){
       updateObj('xmlData', rc4(get("pw"),base64ToText(xmlObj.responseXML.getElementsByTagName('data')[0].firstChild.data)));
    }

rc4 en base64totext verzorgen de decryptie, get haalt de desbetreffende info uit de url, en data is de
xmltag waar de gehashte boodschap/inhoud zit, en bevat cdata.

[AtleX]

Ik heb het als volgt gedaan:

JavaScript:

if (xmlhttp.status==200)
    {
        document.getElementById(element_id).innerHTML = xmlhttp.responseText;
    }
else
    {
        document.getElementById(element_id).innerHTML = 'Gegevens tijdelijk niet beschikbaar';
    }

Bij de response code 200 (HTTP OK) doe ik wat met de data, in alle andere gevallen geef ik gewoon een generieke melding weer.

[ Voor 8% gewijzigd door AtleX op 28-09-2005 20:49 ]

[crisp]

Enkel status 200 is niet voldoende; in het geval van bijvoorbeeld gecachede content kunnen sommige browsers ook de originele HTTP status van de server weergeven (bijvoorbeeld een 304 - Not Modified) terwijl de content toch beschikbaar is (vanuit de browsercache).
In het algemeen is alles >= 200 en < 400 OK, maar daarna zal je in deze volgorde ook het volgende moeten checken:

- bestaat de responseText en/of responseXML property en bevat deze data
- in het geval van XML: bestaat de documentElement property van de responseXML
- is de tagName van het documentElement object wat je verwacht en niet bijvoorbeeld 'parsererror' (welke IE genereerd in het geval de XML mallformed was)

Kijk eens naar de handleXML functie van onze eigen implementatie

[Verwijderd]

Bedankt
Dus nadat ik op een goed spoor werd gezet heb ik de code dus lichtjes aangepast:

JavaScript:

xmlObj.onreadystatechange = function(){
   
   if (xmlObj.readyState==4) {
   if (xmlObj.status==200) {updateObj('xmlData', xmlObj.responseXML.getElementsByTagName('data')[0].firstChild.data);}
    else if (xmlObj.status==404) {document.getElementById('xmlData').firstChild.data = 'De opgegeven gebruiker bestaat niet.';}
     else {document.getElementById('xmlData').firstChild.data = "Status is "+xmlObj.status}
  }

   
   
}
   
   xmlObj.open ('GET', file, true);
   xmlObj.send ('');

}

Nu nog juist een probleem met myn decrypt in ff oplossen (ff only :-?) terwijl deze op voorhand werkte, maar dat zal slechts kwestie van debuggen zijn.
Resultaat: geen errors meer, maar een mooie 'de opgegeven gebruiker bestaat niet' error.

Edit: crisp z'n post nog niet volledig gelezen, moet controles nog invoeren.

Postedit: hmz de controles in de T-versie is ietwat uitgebreider, vanwaar hebben jullie al die informatie verzameld als ik vragen mag ? (knap staaltje controle imo, zelfs activeX wordt ng eens extra gecontroleerd ). En geeft het als ik ideeen copy/paste naar mijn script, afgezien van het werk dat in jullie script steekt.

[ Voor 31% gewijzigd door Verwijderd op 28-09-2005 22:51 ]

[AtleX]

crisp schreef op woensdag 28 september 2005 @ 22:41:
Enkel status 200 is niet voldoende; in het geval van bijvoorbeeld gecachede content kunnen sommige browsers ook de originele HTTP status van de server weergeven (bijvoorbeeld een 304 - Not Modified) terwijl de content toch beschikbaar is (vanuit de browsercache).

Ik stuur vanwege hetzelfde probleem al op de frontpage van Tweakers (100% CPU load en een crash van FF) 2 headers mee:

code:

Cache-Control: max-age=0
Expires: Sat, 06 Apr 2002 11:34:01 GMT

Het is me nog geen 1x voorgekomen dat ik zo een 304 oid terugkreeg, dus voor mij was dit wel voldoende.

[crisp]

AtleX schreef op donderdag 29 september 2005 @ 08:51:
[...]

Ik stuur vanwege hetzelfde probleem al op de frontpage van Tweakers (100% CPU load en een crash van FF) 2 headers mee:

code:

Cache-Control: max-age=0
Expires: Sat, 06 Apr 2002 11:34:01 GMT

Het is me nog geen 1x voorgekomen dat ik zo een 304 oid terugkreeg, dus voor mij was dit wel voldoende.

Dat is het punt; op de frontpage willen we *juist* dat de XML clientside gecached wordt, en bij vervolgrequests die een If-Modified-Since header hebben die binnen onze cache-interval ligt sturen we zelf een 304 terug.
Maar je brengt me wel op een idee voor een mogelijke workaround voor het FP probleem (Ff 1.0.x stuurt namelijk een expliciete no-cache header itt Ff 1.5)

[AtleX]

Dat jullie willen cachen is waarschijnlijk vanwege het dataverkeer. Ik heb dat opgelost door middel van gzip compressie. De site waarvoor ik het xmlHTTPrequest ding heb geschreven haalt verschillende newsfeeds op, 9 feeds per 5 minuten a uncompressed 2,5 KB/stuk. Met gzip compressie is het slechts 700 bytes per stuk, dat scheelt behoorlijk wat dataverkeer.

[crisp]

gzip compressie gebruiken wij ook, maar er zijn een aantal 'feeds' die relatief statisch zijn (bijvoorbeeld de pricewatch categorieën) die we daarnaast liever clientside gecached zien voor een bepaalde periode.
Je praat toch over aardig wat hits - zo'n beetje elke pageview genereerd een request naar een dergelijke feed.

Edit: helaas wil het expliciet terugsturen van no-cache headers aan Ff 1.0.x ook niet helpen; zelfs een expliciete Connection: close niet - Ff lijkt gewoon intern in een loop te geraken...

[ Voor 23% gewijzigd door crisp op 29-09-2005 11:18 ]

[Verwijderd]

Ik vermijd liever het gebruik van xml-cache, aangezien dit probleem ook elders bekend is.
Lijkt me dus dat GZip en de bijhorende servercpu-belasting achterhaald is, aangezien dit dus blijkbaar ook wordt ingezet bij een hoog aantal page-views.

JavaScript:

XmlHttp.create = function () {
    try {
        if (window.XMLHttpRequest) {
            var req = new XMLHttpRequest();
            
            // sommige versies Moz incorrecte readyState en onreadystate eigenschap ondersteuning patch
            if (req.readyState == null) {
                req.readyState = 1;
                req.addEventListener("load", function () {
                    req.readyState = 4;
                    if (typeof req.onreadystatechange == "function")
                        req.onreadystatechange();
                }, false);
            }
            
            return req;
        }
        if (window.ActiveXObject) {
            return new ActiveXObject(getXmlHttpPrefix() + ".XmlHttp");
        }
    }
    catch (ex) {}
    // Niet dus
    throw new Error("Jouw browser ondersteunt XmlHttp objecten niet");
};

Heb best ook aan mijn script gewerkt, ik heb dus in het T.net script ontdekt dat er verschillendeactiveX implementaties zijn, ff gegoogled en allen weergevonden. Ik gebruik nu dan ook een aparte functie (activexobject()) die de juiste (meestal MSXML2-like) activeX eruit haalt, en vervolgens met deze voortparsed.
Maar het probleem zit als volgt nu, de ff browser onreadystatechange en readystatechange hebben nu last van bugs in sommige versier.
dus als readystatechange niet ondersteund wordt, dan onreadystatechange ook niet, daarom wordt onload dan aangeraden.
Maar hoe moet ik deze gepatchte versie voorzien van een degelijke >200 <400 structuur voorzien zonder
onvoorzienigheden in browsers die niet op mijn pc staan om te testen? Of is het gebruik ervan ook waterdicht in oudere browserversies, want ik kan niet direct iets hierover vinden op het internet. Ik dacht eerder aan de typoff .. function if-statement uit te bereiden, maar dan moet het ondersteunen ook nog geverifieerd worden, zonder al te onstrict te werken dan .

Edit: ik verwacht niet dat dit script werkt in uberoude browsers (4-series, of opera dmv iframes), maar toch liefst in ie5 en ff1.0 e.d.

Edit2: laat ook maar .. ik zocht ietwat te ver naar een oplossing voor dit probleem, de if-voorwaarde uitbereiden was idd de oplossing.

[ Voor 17% gewijzigd door Verwijderd op 29-09-2005 21:36 ]

[AtleX]

crisp schreef op donderdag 29 september 2005 @ 10:23:
Edit: helaas wil het expliciet terugsturen van no-cache headers aan Ff 1.0.x ook niet helpen; zelfs een expliciete Connection: close niet - Ff lijkt gewoon intern in een loop te geraken...

Als het je kan helpen, alle headers die ik terugstuur:

code:

Date: Thu, 29 Sep 2005 19:54:20 GMT
Server: Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7a PHP/4.3.11 mod_perl/1.29 FrontPage/5.0.2.2510
X-Powered-By: PHP/4.3.11
Cache-Control: max-age=0
Expires: Sat, 06 Apr 2002 11:34:01 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

200 OK

[crisp]

AtleX schreef op donderdag 29 september 2005 @ 21:55:
[...]


Als het je kan helpen, alle headers die ik terugstuur:

code:

Date: Thu, 29 Sep 2005 19:54:20 GMT
Server: Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7a PHP/4.3.11 mod_perl/1.29 FrontPage/5.0.2.2510
X-Powered-By: PHP/4.3.11
Cache-Control: max-age=0
Expires: Sat, 06 Apr 2002 11:34:01 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

200 OK

Ik stuur iets uitgebreidere no-cache headers terug in het geval van Firefox 1.0.x:

PHP:

header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: pre-check=0, post-check=0, max-age=0', false);
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $now) . ' GMT');
header('Pragma: no-cache');

en natuurlijk ook een Connection: close, en uiteraard een Content-type: text/xml omdat het hier om XML gaat.
Ik kan nog wel eens proberen met alleen een Expires en max-age=0, maar ik ben bang dat dat geen soelaas gaat bieden.
Note trouwens wel dat ik gebruik maak van een synchroon request.