Relaesewechsel im GAD-Rechenzentrum - Ursache HTTP-Fehler ??

HNHBK:1:3+000000000457+300+0+1'
HNVSK:998:3+PIN:2+998+1+1::3E82oAm/6j4BAAD4inEm50RBCgQA+1:20130530:151100+2:2:13:@8@00000000:5:1+280:########:#########:V:0:0+0'
HNVSD:999:1+@267@HNSHK:2:4+PIN:2+942+1+1+1+1::3E82oAm/6j4BAAD4inEm50RBCgQA+20+1:20130530:151100+1:999:1+6:10:16+280:######:#########:S:0:0'
HKIDN:3:2+280:######+VRK###################+3E82oAm/6j4BAAD4inEm50RBCgQA+1'
HKVVB:4:3+93+9+1+www.kontex.de 2013.0525.0+PR669'
HNSHA:5:2+1++#####'
'
HNHBS:6:1+1'

Ja:
- Menupunkt "Stammdaten" -> "Programm-Einstellungen"
- 2.Tabreiter "Debugging" -> "nur für Administratoren"
- die 3 Combo auf <Nein> setzen

Hast du selber bei der Installation auf <Ja> gesetzt, per Default sind diese nicht eingeschaltet

Und noch einen Hinweis:
Ein Traffic-Trace lässt sich wie folgt einschalten:
- Verzeichnis ..\Daten
- Datei "PR669_WinSockTrace.INI" per Texteditor anlegen
- den Text "Trace = JA" reinschreiben

In Verzeichnis ..\Daten\Log wird dann eine LOG-Datei über den durchgeführten Traffic ausgegeben.
Aber der User obnutzer ist der Meinung so ein Trace sagt garnichts

Der Port 443 ist fest im Programm hinterlegt !
M.W. gibt es keine andere Kommunikations-Möglichkeit als den Port 443.
Der Auswahl-Schalter stammt wohl noch aus der Zeit als HBCI über HTTP und Port 3000, unverschlüsselt und nicht Base64-codiert möglich war. (glaub im Jahr 2005 als das geändert wurde)
Bei allen Kunden ist HTTPS eingestellt.

Übrigens hat mir die GAD-Serviceline soeben per EMail mitgeteilt
- das Problem wird weiter analysiert, ist schwierig
- tritt lediglich mit unserer Softwareware auf, andere Meldungen gibt es nicht
- das man jetzt Feierabend macht (nein das stand da nicht, sondern "schönes Wochenende")
- ich möge noch Geduld haben.

Naja ab Dienstag bin ich mit der Familie 2 Wochen auf Malle, hab mir schon gedacht das ich das Problen mit in den Urlaub nehme.

Für die betroffenen Kunden hab ich übrigens die Taskplaner-Lösung, d.h. die Abrufe werden stündlich 24/7 versucht und bei Erfolg in einen Zwischenspeicher abgelegt. Wenn die Buchhalter dann vormittags die Fibu bearbeiten ist die Wahrscheinlichkeit groß es im Laufe der Nacht der Abruf mal geklappt hat und die Daten bereit stehen.

Gibt es evtl. in Kontex einen Unterschied bei der Bearbeitung von Frames mit "Transfer-Encoding: chunked"?

Nachtrag:
Es ist ja auch garnicht möglich im Anfrage-Header "Transfer-Encoding" zu übergeben. Jedenfalls ist diese in dieser Liste nicht aufgegeführt:Anfrage-Headerfelder

Macht ja auch keinen Sinn. Wird ja nur verwendet wenn die Größe der übertragenden Daten (noch) nicht bekannt ist. Auf der Anfrage-Seite sind diese aber immer bekannt.

Ausgehend von diesem Gedanke hab ich mal versucht die Anfrage per HTTP/1.0 zu schicken und der Hoffung der Server antwortet auch nur mit HTTP/1.0 weil dann kein Transfer-Encoding als Antwort kommen würde.
Vergeblich, Server antwortet trotzdem mit HTTP/1.1

Danke für den Link.
Bestätigt mich in der Annahme "IP-Problem" - auf der Server-Seite.
(wie bereits im Posting 30 Mai, 2013 14:33 vermutet)
Aber warum *nur* in unserer Anwendung ?

Gute Nacht

mfg
Wolfgang

Richtig und betroffen könnte Kontex ja auch nur sein, wenn Java zum Einsatz kommt.
Erinnert mich an das historische "MTU-Problem". Das war mal mein "Lieblingsproblem" aus den Anfangsjahren, wenn gerade SSL-Netzwerkverbindungen sporadisch nicht funktionierten:
http://www.onlinebanking-forum…php?t=1198

Hier hat man nämlich auch gewaltige Probleme, den "schwarzen Peter" zu finden: Der Bankserver hat "schuld", weil er die fragmentierten Pakete nicht akzeptiert, die der Sender aber am besten gar nicht senden sollte...

Trifft hier nicht zu, hat aber ähnliche Effekte.

Gruß
Raimund

+++ Läuft wieder ??? +++

Seit 07:15h sind alle Umsatz-Abrufe bei all unseren Anwendern immer erfolgreich, der Fehler 503 ist seitdem nicht mehr aufgetreten.
Zwischen 07:07-07:15h muss es eine Änderung im GAD-RZ gegeben haben.

Offiziell bin ich aber bisher ohne Info.

Eben habe ich die offzielle Info erhalten, dass das Problem beseitigt ist.
Kann ich bis jetzt bestätigen.

Ursache wäre eine abweichende Struktur im HTTP-Header. Diese wurde nun durch Anpassungen im RZ abgefangen.

Finde ich auch RESPEKT!
Mit unseren 120 Anwendern sind wir doch aus GAD-Sicht ein Popel-Laden

Kann weiterhin nur sagen:
- ist min 5 Jahre so ohne Änderungen gelaufen.
- bei den Anderen RZ funkts auch.

Aber egal - Hauptsache es läuft wieder.
Ob ich jemals erfahren werde was es mit den abweichenden Strukten auf sich hat ... ?

Und bin mal gespannt was die anderen User jetzt so meinen, die auf mich eingeprügelt haben.

@onlbanker

Wenn du es einsieht dann ist schon OK.
Der 19-jährige der vorgestern in Aurich verurteilt wurde, hat bestimmt auch sein Lektion gelernt.

Ich war zu diesem Zeitpunkt überhaupt froh mit jemanden zu diskutieren, die Kommunikation mit GAD war ja weniger als dürftig. Da kam immer nur "in Arbeit, schwierig, dauert noch".

Aber zum Glück haben die das intern doch bearbeitet, und nicht mich abgewimmelt, wie das ja hier im Forum passiert wäre. Aber ich war mir meiner Fakten sicher.