HTTPClient :getStatusCode

Vom Front-End bis SOAP.

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13878
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 3 Mal
Danksagung erhalten: 4 Mal
Kontaktdaten:

HTTPClient :getStatusCode

Beitrag von Jan » Sa, 22. Aug 2020 12:54

Hallo,

bei Arbeiten it HTTPClient kann ich ja hinterher den Statuscode und -text abfragen. Die Werte sind insgesamt bekannt aus anderen Umgebungen.

Allerdings gibt es da auch einen Wert -1 "Operating system or other non-protocol error". WIe muß ich das verstehen? Ist das ein Problem auf dem angesprochenen Server? Oder eher ein Problem auf dem Rechner/Server, auf dem das Programm mit dem HTTPClient-Aufruf läuft? Oder sowohl als auch?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15214
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 6 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von brandelh » So, 23. Aug 2020 7:33

Ich denke (!) es muss lokal sein, denn alle anderen HTTP Fehler-/Statusmeldungen sind ja dokumentiert.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8172
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 5 Mal
Danksagung erhalten: 25 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Tom » So, 23. Aug 2020 9:43

So, wie es da steht. Es ist ein Betriebssystemfehler (der einen eigenen OS-Statuscode hat) oder ein bislang nicht im Protokoll berücksichtigter Fehler aufgetreten.
Herzlich,
Tom

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8172
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 5 Mal
Danksagung erhalten: 25 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Tom » Mo, 24. Aug 2020 9:41

Sorry, Jan, ich habe das erst jetzt richtig gelesen. "HttpClient:getStatusCode()" retourniert den "HTTP status code", darunter die berühmte 404 dafür, dass der Request eine Ressource angefordert hat (also ein Dokument oder ein Script o.ä.), das nicht (mehr) bekannt ist. "-1" sammelt die nicht kategorisierbaren Fehler; es kann sich um einen Betriebssystemfehler handeln, aber auch um irgendwas sonst, doch es sind Serverfehler beim Versuch, den Request zu beantworten. Aber, Achtung, auch die können ja durch den Request ausgelöst werden. Oder, anders gesagt: Ein fehlerhafter Request kann sie zur Folge haben. Deshalb muss man sich eigentlich beides ansehen, also den Request und die sonstigen Logs des Servers.
Herzlich,
Tom

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13878
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 3 Mal
Danksagung erhalten: 4 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Jan » Mo, 24. Aug 2020 10:14

Hallo Tom,

nach Deiner ersten Antwort hatte ich heute früh direkt meine Protokollierung erweitert. Und frage jetzt auch den DosError() ab bei einem HTTP-Code von -1. Ergebnis: "0 Der Vorgang wurde erfolgreich beendet." Das passt zu Deiner letzten Aussage das der Fehler selber auf dem Server passiert.

Wenn nun die Doku zu HTTPClient():getStatusCode() mir sagt "The value -1 denotes an internal error not handled on the protocol-level. In this case, there is no HTTP status code.", und es kein Betriebssystemfehler ist - unterstelle ich dann damit einem Konzern wie GLS, das die da Abfrageprobleme haben die die keinem HTTP-Code zuweisen? Ist das schleichender Größenwahn?

Ich bezweifle mal das es keine Probleme mit meinem Request gibt. Der ist immer absolut identisch bis auf den Parameter mit der Paketnummer. Und funktioniert viele Tausend mal am Tag. Bei ca. einem ‱ kommt dieser Fehler -1.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8172
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 5 Mal
Danksagung erhalten: 25 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Tom » Mo, 24. Aug 2020 10:31

Hallo, Jan.

Ich bin in der vergangenen Woche mit der Bahn gefahren, von Berlin nach Essen. In "Bielefeld" (<hüstel>) gab es eine Störung, deshalb musste der Zug über Löhne umgeleitet werden, außerdem wurden deshalb nach und nach Endbahnhöfe gestrichen. So ist das eben bei der Bahn. Aber das Lustigste daran war eigentlich, was die Status-/Verlaufsanzeige in den Waggons die ganze Zeit angezeigt hat, auf diesen Monitoren an der Waggondecke. Das war, vorsichtig gesagt, ein ziemlich turbulentes Durcheinander. Am Anfang, mit der ersten Störungsmeldung, schien es noch zu stimmen, dann glaubte das System offenbar plötzlich, wir wären überhaupt noch nicht in Berlin losgefahren (tatsächlich hielten wir inzwischen auf Hamm zu), schließlich stand die ursprüngliche Haltfolge wieder dort, und so weiter. Eine Absurdität folgte der nächsten, und das alles nur, weil ein Bahnhof ausgefallen war, der Zug inzwischen 80 Minuten Verspätung hatte und ein paar Ziele gestrichen worden waren - Tagesgeschäft für die Bahn. Okay, vielleicht ein bisschen anders als üblich. Aber bei der Rückfahrt am Tag darauf, alle Bahnhöfe fast planmäßig und am Ende nur zehn Minuten Verspätung, war es dasselbe. Plötzlich bootete das System und zeigte wieder an, dass der Zug gleich in Duisburg losfahren würde, obwohl wir kurz vor Hannover waren, dann war's für einen Moment richtig, meistens aber falsch. Man hätte den ganzen Scheiß auch ausgeschaltet lassen können. Die Informationen, die es anzeigte, waren komplett wertlos.

Was ich damit sagen will: Die Bahn ist ja auch nicht gerade ein kleiner Verein, und so ein Zug-Informationssystem wird vermutlich nicht von einem Programmierer alleine entwickelt, und trotzdem ist es ohne Frage totaler Schrott. Mag sein, dass es funktioniert, wenn nichts schiefgeht, aber da statistisch betrachtet 170 Prozent aller Züge mehr als drei Tage Verspätung haben, dürfte das nie der Fall sein - das System ist für eine Ausnahme gebaut, die nie eintritt. Die Aufgabenstellung ist überschaubar, für die Datenquellen dürfte ähnliches gelten, und trotzdem funktioniert es nicht. Ich bin davor zuletzt vor einem Dreivierteljahr Bahn gefahren, und da war es ähnlich. Plötzlich zeigte das Ding wieder an, dass wir gleich am Bahnhof Berlin-Südkreuz losfahren würden, aber eigentlich waren wir schon kurz vor München. Sie kriegen es nicht einmal hin, diesen Mist zu reparieren. Ein bisschen Markup, ein paar Tabellen, ein überschaubares Protokoll. Juhu.

Die Größe des Ladens, dem man gegenübersitzt, sagt nichts über die IT-Qualität aus. Und Serverprogrammierung ist sowieso ein Thema für sich. Ich halte es für denkbar, dass Du bei tausend Requests einmal auf einen Serverfehler trittst. Das ist sogar noch relativ wenig. Also: Request merken und im Fehlerfall abermals absetzen. Wird schon nicht schiefgehen. 8)
Herzlich,
Tom

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15214
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 6 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von brandelh » Mo, 24. Aug 2020 13:05

Es ist kein HTTP Fehler, aber es könnte der Hinweis auf gar keine Antwort (Timeout) sein, endgültig kann das aber nur Alaska beantworten.
Bei mir raucht in letzter Zeit mal häufiger die DSL Leitung ab ... 10 minuten Timeouts, bis die wieder neu verhandelt haben :(

Wobei, bei meinen CGI EXE - die wegen einem Fehler abstürzen - gibt der Server nach seinem TimeOut Bad Request als Antwort an den Browser zurück.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8172
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 5 Mal
Danksagung erhalten: 25 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Tom » Mo, 24. Aug 2020 13:48

Ob das auf ein Timeout zurückzuführen ist, was ich stark zu bezweifeln wage, kann man ja leicht dadurch herausbekommen, dass man den fraglichen Request an eine falsche URL absetzt, oder ohne bestehende Internetverbindung. Oder man schaut, was passiert, wenn man HttpClient:SetTimeout() mit einem so niedrigen Wert (z.B. eine Millisekunde) bestückt, dass eigentlich immer ein Timeout eintreten muss. Ich verwendet HttpClient() nicht, weil ich mit Xb2Net arbeite, aber Timeouts führen m.E. nicht zu Serverfehlern. Sollte das dennoch der Fall bei Dir sein, Jan, kannst Du den Wert (bzw. die Werte - SetTimeout setzt ja bis zu 4 Timeouts) ja mal hochsetzen.
Herzlich,
Tom

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Di, 25. Aug 2020 8:56

brandelh hat geschrieben:
Mo, 24. Aug 2020 13:05
Bei mir raucht in letzter Zeit mal häufiger die DSL Leitung ab ... 10 minuten Timeouts, bis die wieder neu verhandelt haben :(
Versuch doch mal dem Router ein neues Netzteil zu verpassen. Einige der billigen China Ware werden oft nach kurzer Zeit instabil was zu Router-Resets oder massiver Störspannungen im DSL Frequenzbereich führt ....
Valar Morghulis

Gruss Carlo

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Di, 25. Aug 2020 9:00

Hallo Jan

wieviele Request's sendest du denn überhaupt? Könnte es sein dass z.B. die möglichen/erlaubten Sessions pro Zeiteinheit im Router aufgebraucht sind und z.T. keine Verbindung mehr aufgebaut werden kann bezw. zulässig ist ?
Valar Morghulis

Gruss Carlo

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13878
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 3 Mal
Danksagung erhalten: 4 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Jan » Di, 25. Aug 2020 9:26

Moin,

ich geh mal hier gesammelt auf Eure letzten Kommentare ein.

Timeout ist eher unwahrscheinlich, dafür geht das alles dann doch zu flott. Sowas verzögert ja schon sehr bemerkbar, was aber nicht der Fall ist.

Der Router ist eindeutig in Ordnung. Billigware steht bei meinem Kunden sowieso nicht. Nur ziemlich teure Ware von HP, Dell, etc für einen guten sechsstelligen Betrag in zwei getrennten Rechenzentren. Alleine die beiden Core-Switches haben schon weit mehr gekostet als mein PKW ...

Das sind ca. alle 1/2 Stunde mindestens 1.500 Requests (zur Zeit, in der Saison auch mal locker das zehnfache). Die Ausfälle kommen sehr sporadisch immer zwischendurch. Allerdings gehäuft früh morgens oder nach Feierabend.

GLS ist zur Zeit noch am testen, was da passieren könnte. Die ziehen sich den Schuh also zumindest aktuell durchaus an. Bislang haben die sich aber noch nicht wieder gemeldet.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Di, 25. Aug 2020 9:35

Nur ziemlich teure Ware von HP, Dell, etc für einen guten sechsstelligen Betrag in zwei getrennten Rechenzentren. Alleine die beiden Core-Switches haben schon weit mehr gekostet als mein PKW ...
Ja genau. Bei denen bezw. in der Firewall Abteilung kann man meist einstellen wieviele verschiedene Session eine IP-Adresse oder Netzwerk pro Zeiteinheit haben darf bezw. zulässig ist ...... (session limit)

Schau doch mal das Routerlog an.

Ich kenn das Problem mit den grossen Fortinet Geräten.¨


Es ist aber auch möglich dass dein Anfragepartner überlastet ist dann wird
meist die Anfrageverbindung einfach ohne eine Antwort verworfen.
Da ja die Rückgabe eines HTTP Status Codes auch Ressourcen benötigen würde.

Ich würde deine Abfrage Fehlertolerant aufbauen und nach einer kuren Wartezeit einfach
wiederholen und erst in einen Fehler gehen wenn die z.B. 5 Mal in 10 Skunden Auftritt.
Valar Morghulis

Gruss Carlo

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13878
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 3 Mal
Danksagung erhalten: 4 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Jan » Di, 25. Aug 2020 10:35

Carlo,

genau das baue ich gerade ein. Denn der Fehler scheint wirklich nur sporadisch zu kommen, nicht abhängig von dem jeweiligen angefragten Paket. So etwas habe ich an anderer Stelle der GLS-Abfragen auch schon drin, da gehe ich max. 10x im Abstand von zwei Sekunden in die Schleife.

Dennoch muß GLS kontrollieren, was da schief läuft. Denn einen Status ohne Kennung sollte es natürlich nie geben. Und wenn die nur irgend eine 500er Meldung zurückgeben, um auf eine Serverproblem hinzuweisen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Di, 25. Aug 2020 10:56

Jan hat geschrieben:
Di, 25. Aug 2020 10:35
Denn einen Status ohne Kennung sollte es natürlich nie geben. Und wenn die nur irgend eine 500er Meldung zurückgeben, um auf eine Serverproblem hinzuweisen.
Diese Annahme ist in der Praxis völlig falsch.
Alle Webserver die ich bereits getestet habe geben bei richtiger überlastung gar keine Antwort mehr sondern beenden einfach nur die Verbindung.
(oder hängen sich auf. Ping of Death )
Ohne einen HTTP Code. Dies weil Sie ja überlastet sind und gar keine Resourcen mehr haben um eine Verbindung anzunehmen oder irgendeine Antwort zu senden.
Zuletzt geändert von ramses am Di, 25. Aug 2020 11:04, insgesamt 1-mal geändert.
Valar Morghulis

Gruss Carlo

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 8172
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 5 Mal
Danksagung erhalten: 25 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Tom » Di, 25. Aug 2020 11:02

Wenn der Server nicht erreichbar ist, weil alle Ports dicht sind, bekommt man auch keine 500. Das ist nämlich eine Serverantwort. Ich würde das abfangen und protokollieren und den Sendeversuch einfach wiederholen, wenn das geht. Und die Protokolle dann mit der IT des Kunden durchgehen.
Herzlich,
Tom

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13878
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 3 Mal
Danksagung erhalten: 4 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von Jan » Di, 25. Aug 2020 11:11

Carlo,

ich seh da einen Unterschied zwischen "Überlastet" (führt vermutlich zu Timeout) und -1 (vermutlich ein vom Server nicht zugewiesenes Problem).

Und wie gesagt, zumindest die -1 wird zukünftig zwar weiterhin protokolliert werden für die GLS-IT, aber hier passend abgefangen durch noch mal versuchen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Di, 25. Aug 2020 11:21

Jan

der Statuscode gibt dir die Antwort des Server zurück z.B. 500 wenn dieser noch Resourcen zum Antworten hat. Hat er die nicht und verwirft/beendet die Verbindung ist es aus Sicht der HTTP Ebene ein Hardwarefehler und du bekommst eben -1 zurück........
Valar Morghulis

Gruss Carlo

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15214
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 6 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von brandelh » Di, 25. Aug 2020 11:43

Jan hat geschrieben:
Di, 25. Aug 2020 11:11
Carlo,

ich seh da einen Unterschied zwischen "Überlastet" (führt vermutlich zu Timeout) und -1 (vermutlich ein vom Server nicht zugewiesenes Problem).

Und wie gesagt, zumindest die -1 wird zukünftig zwar weiterhin protokolliert werden für die GLS-IT, aber hier passend abgefangen durch noch mal versuchen.

Jan
Hast du mal bei Alaska nachgefragt ob die -1 vom (externen Web Server) oder vom sendenden PC (unbekannter OS Fehler, Netzwerkkarte überlastet etc.) her kommt ?
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15214
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 6 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von brandelh » Di, 25. Aug 2020 22:32

Eigentlich ist die Beschreibung eindeutig:

HTTP Status Codes, sind Protokoll Status Meldungen von OK (200) bis 40x ...
Errors occuring outside the protocol stack, for example, operating system errors due to resource issues,
are reflected using the special status code -1.
Fehler außerhalb des Protokoll Stacks, also der HTTP Antwort des Servers (zu der Abfrage kommt es gar nicht,
denn ... Betriebssystemfehler wegen mangelnder Resourcen ... Stack Overflow, Netzwerkkarte überlastet etc.)
Klingt irgendwie nach der Art wie früher Disketten oder Drucker einfach nicht machten was man will.
Tom hat ja die Antwort gegeben, mehrfach probieren.

Code: Alles auswählen

In this case, the methods :getLastError() and :getLastMessage() can be used for getting more information about the error. 
mit diesen Methoden soll man die Ursache eingrenzen.

Auf keinen Fall hat Xbase++ oder das aktuelle Client Betriebssystem Zugriff auf das Betriebssystem des HTTP/FTP/TCP Servers.
Gruß
Hubert

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Mi, 26. Aug 2020 7:39

Ich kann nur noch mal darauf Hinweisen:

Wenn z.B. ein Server überlastet ist und die Verbindung die du Aufbaust ohne irgendeine Antwort einfach beendet/schliesst ist die Rückgabe von HTTPClient:getStatusCode( ) --> -1

Das heisst in dem Fall die Verbindung ist korrekt zustande gekommen aber vom Zielserver verworfen worden.

Dies lässt sich übrigens auch sehr einfach mit xb2net als Server überprüfen.

Code: Alles auswählen

1. xb2net Webserver Filterrequest() setzten und z.B. mit folgendem ergänzen:

if ".php" $ cPath .or. ".cgi" $ cPath .or. "cgi-bin" $ cPath .or. ".asp" $ cPath
      FilterLog( "Close  " + cPath + " " + iif(valtype(cRef)="C", cRef+" ", "") + iif(valtype(oClient:RemoteAddr)="C",oClient:RemoteAddr,""), .t. )
      oClient:NoLog := .t. // don't want to record this in the log file
      oClient:close()      // don't bother to respond, just close the connection
      Return .F.
endif


2. Mit HTTPClient einen Request an den server senden z.B. http://server_adresse/test.php


HTTPClient meldet  Statuscode -1
Daher:
Auf keinen Fall hat Xbase++ oder das aktuelle Client Betriebssystem Zugriff auf das Betriebssystem des HTTP/FTP/TCP Servers.
Das stimmt nicht. Die Verbindung wurde ja zu HTTP Server auf dem Zielsystem aufgebaut und von diesem beendet.
Valar Morghulis

Gruss Carlo

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15214
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 6 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: HTTPClient :getStatusCode

Beitrag von brandelh » Mi, 26. Aug 2020 12:47

ramses hat geschrieben:
Mi, 26. Aug 2020 7:39
Daher:
Auf keinen Fall hat Xbase++ oder das aktuelle Client Betriebssystem Zugriff auf das Betriebssystem des HTTP/FTP/TCP Servers.
Das stimmt nicht. Die Verbindung wurde ja zu HTTP Server auf dem Zielsystem aufgebaut und von diesem beendet.
Deinen anderen Anmerkungen schließe ich mich gerne an, aber dass der Zugriff auf einen Port (beantwortet oder nicht),
ein Zugriff auf das Betriebssystem des Zielsystems sein soll, das dann z.B. Betriebssystemfehler codes meldet, das glaube ich nicht.
Die -1 kommt wahrscheinlich vom Betriebssystem des Client-Rechners, der das Schließen der Verbindung ohne Antwort mit dem Fehler code dokumentiert.
Gruß
Hubert

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1876
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 1 Mal
Danksagung erhalten: 6 Mal

Re: HTTPClient :getStatusCode

Beitrag von ramses » Mi, 26. Aug 2020 13:51

Hallo Hubert

der Verbindungsaufbau in meinem Beispiel oben mit Xb2 ist ein erfolgreicher Verbindungsaufbau vom ClientRechner zum Betriebssystem und Serverprogramms des Zielsystems.

Das Serverprogramm erhält den Request und schliesst einfach die Verbindung. Das ist doch eine erfolgreich zustandegekommene Verbindung bezw. Zugriff auf das Zielsystem auch wenn dieser die Verbindung einfach und ohne Antwort schliesst und beendet.

Der HTTPClient antwortet mit -1 etwas anders kann er ja nicht weil er vom Server auch keinen Statuscode erhalten hat.
Es heisst ja in der DOC getStatusCode() gibt den vom Server erhaltenen Statuscode zurück oder eben in allen anderen Fällen -1

Bei solchen Anfragen die Jan macht erwartet man doch bei erfolgreicher Ausführung 200 zurück alles andere muss auf Fehler bewertet oder erneut abgefragt werden. So ist z.B. bei Digest_Auth auch 401 möglich was die Anforderung zu Digest Auth mit Username und Passwort sein kann. (RFC 7235)

Mit xbHTTPClient() wären auch alle Socketfehler erkennbar. Wie dies mit HTTPClient von Xbase geht weiss ich nicht. Aber Jan hat ja einen guten Draht zu Alaska........
Valar Morghulis

Gruss Carlo

Antworten