Zum Inhalt springen

API Endpunkte liefern unregelmäßig "400 - Bad Request" zurück


filyra

Empfohlene Beiträge

Ich habe mehrere Endpunkte angebunden. Wenn ich z.B. GET https://api.bitcoin.de/v4/permissions abfrage, bekomme ich "immer wieder mal" eine 400 - Bad Request zurück. Dabei verändere ich die Requests z.B. in Postman nicht. Manchmal erhalte ich die korrekte Response, manchmal die 400. Indeterministisch.

Was ist hier der Grund? Thx

Link zu diesem Kommentar
Auf anderen Seiten teilen

11 minutes ago, filyra said:

Ich habe mehrere Endpunkte angebunden. Wenn ich z.B. GET https://api.bitcoin.de/v4/permissions abfrage, bekomme ich "immer wieder mal" eine 400 - Bad Request zurück. Dabei verändere ich die Requests z.B. in Postman nicht. Manchmal erhalte ich die korrekte Response, manchmal die 400. Indeterministisch.

Was ist hier der Grund? Thx

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).

 

https://www.ionos.com/digitalguide/hosting/technical-matters/http-400-bad-request-finding-the-causes/

Bearbeitet von Chantal Krüger
Link zu diesem Kommentar
Auf anderen Seiten teilen

As stated the request was totally correct. In particular the answer sometimes is as expected and sometimes 400. Its just random. Of course I am aware what a 400 is. As this is not deterministically this might be an error in the API.

Bearbeitet von filyra
Erweiterung
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 25 Minuten schrieb filyra:

Ich habe mehrere Endpunkte angebunden. Wenn ich z.B. GET https://api.bitcoin.de/v4/permissions abfrage, bekomme ich "immer wieder mal" eine 400 - Bad Request zurück. Dabei verändere ich die Requests z.B. in Postman nicht. Manchmal erhalte ich die korrekte Response, manchmal die 400. Indeterministisch.

Was ist hier der Grund? Thx

Vielleicht hast du zu viele Zugriffe und du bekommst ab und an ein Timeout?

Link zu diesem Kommentar
Auf anderen Seiten teilen

11 minutes ago, filyra said:

As stated the request was totally correct. In particular the answer sometimes is as expected and sometimes 400. Its just random. Of course I am aware what a 400 is. As this is not deterministically this might be an error in the API.

Ich habe nur die Seite kopiert. 400 ist ein Problem mit der Servercommunikation. Ich habe das immer früher gehabt, wenn die API auf Serverseite upgedatet wurde und meine requests nicht mehr funktionierten. Hast Du das überprüft. 

Ich logge das immer so, dass ich genau weiss, welche Request wann welche Fehlermeldung erzeugt und kann damit genau sagen, wo der Fehler ist. 400 kommt nicht von alleine. Da würde ich mal checken.

Link zu diesem Kommentar
Auf anderen Seiten teilen

3 minutes ago, coinflipper said:

Vielleicht hast du zu viele Zugriffe und du bekommst ab und an ein Timeout?

die 4xx Fehler beziehen sich normalerweise auf "faulty requests" vom Client. Der Fehler liegt auf seiner Seite.

HIer ist das ganz gut erklärt und was man machen kann : 

https://www.ionos.com/digitalguide/hosting/technical-matters/http-400-bad-request-finding-the-causes/

Bearbeitet von Chantal Krüger
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Minuten schrieb Chantal Krüger:

die 4xx Fehler beziehen sich normalerweise auf "faulty requests" vom Client. Der Fehler liegt auf seiner Seite.

macht Sinn. Ich dachte wenn man ein timeout bekommt, wird die IP gesperrt, sodass man eventuell ein Error 400 bekommt.

Hier ist der Auszug aus den Fehlercodes der API: https://binance-docs.github.io/apidocs/spot/en/#error-codes

Link zu diesem Kommentar
Auf anderen Seiten teilen

2 minutes ago, coinflipper said:

macht Sinn. Ich dachte wenn man ein timeout bekommt, wird die IP gesperrt, sodass man eventuell ein Error 400 bekommt.

Hier ist der Auszug aus den Fehlercodes der API: https://binance-docs.github.io/apidocs/spot/en/#error-codes

Der einzige Weg, den Fehler zu finden, ist nachzusehen, was er sendet und was der Server will. Dann noch Cockies und den ganzen Müll löschen und wieder probieren.

Mit der IP Sperre kann sein, aber ich dachte, die senden dann was anderes. (an den Code kann ich mich gerade nicht erinnern).

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 19 Minuten schrieb coinflipper:

Vielleicht hast du zu viele Zugriffe und du bekommst ab und an ein Timeout?

Das habe ich auch getestet. Auch wenn ich lange keinen Request gemacht habe kommt manchmal eine 400. Und direkt danach geht es z.B. wieder. Bei too many requests sollte ansonsten laut Doku eine 429 kommen. Ich würde das daher ausschließen.

 

Zitat

die 4xx Fehler beziehen sich normalerweise auf "faulty requests" vom Client. Der Fehler liegt auf seiner Seite.

Dann frage ich mich wieso bei identischem Request es manchmal funktioniert. Indeterministisch. Das deutet eben genau darauf hin, dass es kein Client Fehler ist. ( Ja nochmal, ich weiß sehr genau, was eine 400 bedeutet ;) )

 

Zitat

Der einzige Weg, den Fehler zu finden, ist nachzusehen, was er sendet und was der Server will. Dann noch Cockies und den ganzen Müll löschen und wieder probieren.

Ich arbeite mit Postman und auch mit meinem eigenen Client. Es geht hier nicht um Webseiten Abfragen. Ich habe die Requests mehrfach überprüft. Und wie gesagt: Es funktioniert "manchmal"

 

Ist jemand vom Support in der Nähe? Danke :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

7 minutes ago, filyra said:

Das habe ich auch getestet. Auch wenn ich lange keinen Request gemacht habe kommt manchmal eine 400. Und direkt danach geht es z.B. wieder. Bei too many requests sollte ansonsten laut Doku eine 429 kommen. Ich würde das daher ausschließen.

 

Dann frage ich mich wieso bei identischem Request es manchmal funktioniert. Indeterministisch. Das deutet eben genau darauf hin, dass es kein Client Fehler ist. ( Ja nochmal, ich weiß sehr genau, was eine 400 bedeutet ;) )

 

Ich arbeite mit Postman und auch mit meinem eigenen Client. Es geht hier nicht um Webseiten Abfragen. Ich habe die Requests mehrfach überprüft. Und wie gesagt: Es funktioniert "manchmal"

 

Ist jemand vom Support in der Nähe? Danke :)

Danke für Deine nette Antwort, dann brauchen wir uns auch keine Gedanken mehr machen. Viel Spass beim Fehler finden.

  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 12 Minuten schrieb filyra:

Das habe ich auch getestet. Auch wenn ich lange keinen Request gemacht habe kommt manchmal eine 400. Und direkt danach geht es z.B. wieder. Bei too many requests sollte ansonsten laut Doku eine 429 kommen. Ich würde das daher ausschließen.

Solltest du auf den Fehler nicht drauf kommen, mach ein workaround. Das kann man ja auch relativ einfach umgehen, oder?

EDIT: Oh. ich sehe grade, das ist bitcoin de und nicht binance :D sorry, da habe ich noch nie was mit versucht.

Bearbeitet von coinflipper
Link zu diesem Kommentar
Auf anderen Seiten teilen

Gerade eben schrieb coinflipper:

Solltest du auf den Fehler nicht drauf kommen, mach ein workaround. Das kann man ja auch relativ einfach umgehen, oder?

Die Frage ist ob der Fehler hier liegt. An welchen Workaround denkst du? Ich denke z.B. den Request so oft abfeuern, bis mal die 200 kommt, funktioniert zwar, ist aber keine gute Idee. 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Minuten schrieb filyra:

Die Frage ist ob der Fehler hier liegt. An welchen Workaround denkst du? Ich denke z.B. den Request so oft abfeuern, bis mal die 200 kommt, funktioniert zwar, ist aber keine gute Idee. 

Je nachdem, was dein script können soll. Wenn du einen direkten Abruf machst, einfach eine Error-Anzeige, oder den Fehler aufnehmen und nach ein paar Sekunden erneut abfeuern. Sollte es ein selbständiges Script sein, mach eine "Job"-List. Sodass es einfach im nächsten Durchlauf erneut versucht wird.

Link zu diesem Kommentar
Auf anderen Seiten teilen

7 minutes ago, coinflipper said:

Je nachdem, was dein script können soll. Wenn du einen direkten Abruf machst, einfach eine Error-Anzeige, oder den Fehler aufnehmen und nach ein paar Sekunden erneut abfeuern. Sollte es ein selbständiges Script sein, mach eine "Job"-List. Sodass es einfach im nächsten Durchlauf erneut versucht wird.

Er will jemanden vom Support haben, nix von uns. Er weiss es eben besser, dann Frage ich mich, warum er hier überhaupt fragt ...

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 30 Minuten schrieb coinflipper:

Je nachdem, was dein script können soll. Wenn du einen direkten Abruf machst, einfach eine Error-Anzeige, oder den Fehler aufnehmen und nach ein paar Sekunden erneut abfeuern. Sollte es ein selbständiges Script sein, mach eine "Job"-List. Sodass es einfach im nächsten Durchlauf erneut versucht wird.

Ja mit dem Gedanken habe ich auch schoin gespielt. Es ist aber irgendwo nicht sauber.

Zitat

Er will jemanden vom Support haben, nix von uns. Er weiss es eben besser, dann Frage ich mich, warum er hier überhaupt fragt ...

"nix von uns" stimmt nicht. Nicht böse gemeint, aber die 3- bzw. 4 fache Erklärung was eine 400 ist hat nicht geholfen, auch wenn es gut gemeint war. Die 400 als technische korrekte Antwort hat die Beschreibung ja bereits in Frage gestellt.

Und daher frage ich nach Hilfe vom Support. Da die API nicht deterministisch reagiert und es nicht an den Rates liegt, können wohl nur Leute vom Support mehr dazu sagen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb filyra:

bekomme ich "immer wieder mal" eine 400 - Bad Request

Was genau liefert der Server denn zurück? Einfach so 400 ohne Meldung macht bitcoin.de glaube ich nicht.

Sporadisch hatte ich mal 400er, als ich die Nonce schlecht gewählt hatte oder mehrere Clients gleichzeitig losgeschickt habe. Aber ohne die genaue Fehlermeldung wird's jetzt halt schwer.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb filyra:

a mit dem Gedanken habe ich auch schoin gespielt. Es ist aber irgendwo nicht sauber.

Nicht sauber, ist relativ. Es gibt immer Fälle, wo Server ausfallen. Wenn das, was du machst heikel ist, brauchst du ein Fall back, falls dieser Fall eintritt. Wenn diese sporadischen 400er Error kommen, passen sie in diese Kategorie.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 47 Minuten schrieb coinflipper:

Nicht sauber, ist relativ. Es gibt immer Fälle, wo Server ausfallen. Wenn das, was du machst heikel ist, brauchst du ein Fall back, falls dieser Fall eintritt. Wenn diese sporadischen 400er Error kommen, passen sie in diese Kategorie.

Oh ja.. 400er, 500er, Internet weg, was auch immer...

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 11 Stunden schrieb fox42:

Was genau liefert der Server denn zurück? Einfach so 400 ohne Meldung macht bitcoin.de glaube ich nicht.

Sporadisch hatte ich mal 400er, als ich die Nonce schlecht gewählt hatte oder mehrere Clients gleichzeitig losgeschickt habe. Aber ohne die genaue Fehlermeldung wird's jetzt halt schwer.

400, bad Request. Kannst du genau sagen was an der Nonce falsch war? Es wäre jedenfalls bedenklich seitens des Servers, dass einfalscher Request manchmal durchgelassen wird und manchmal nicht.

Die requestOptions baue ich zB hier: 

function requestOptions({ wallet, uriAsArray, params }) {
  const timestamp = (new Date().getTime() / 1000).toString().replace('.', '');

  let fullUri = uriAsArray.join('');
  if (params && Object.values(params).length > 0)
    fullUri += `?${new URLSearchParams(params).toString()}`;

  return {
    responseType: 'json',
    searchParams: params,
    headers: {
      'X-API-KEY': wallet.api.keys[0],
      'X-API-NONCE': timestamp,
      'X-API-SIGNATURE': crypto
        .createHmac('sha256', wallet.api.keys[1])
        .update(
          [
            'GET',
            fullUri,
            wallet.api.keys[0],
            timestamp,
            crypto.createHash('md5').update('').digest('hex'),
          ].join('#')
        )
        .digest('hex'),
    },
  };

 

Zitat

Nicht sauber, ist relativ. Es gibt immer Fälle, wo Server ausfallen

Nun ja ich frage alle Trades, Deposits und Withdrawals ab. Für alle vorhandenen Assets. Momentan 8 Stück. Und bei dieser Zahl von Calls kommt der Error irgendwann sicher. Das ist nicht schön. Manchmal kommt er sogar bei aller ersten Call (kein Rate Limit)

Link zu diesem Kommentar
Auf anderen Seiten teilen

ich kenn mich technisch überhaupt nicht aus, aber ich hab mal rausgekramt was mir der bitcoin.de support mal geschrieben hatte, als ich häufige Fehler hatte, vielleicht hilft es ja, oder es hat garnichts damit zu tun :D

Zitat
unsere Technik konnte das von Ihnen beschriebene Problem inzwischen nachvollziehen & lösen.
 
Fälschlicherweise wurde im Falle eines fehlgeschlagenen Express-Handels (fehlgeschlagen im 1. Express-Transfer-Versuch) nicht der HTTP-Status-Code 422 von uns zurückgeliefert, sondern ein 302 ("Moved Temporarily"). Dazu beinhaltet der Response einen Location-Header, der die URI zu den Details des korrespondierenden Trades beinhaltet.
 
Ihre Bibliothek, mit der sie die Trading-API ansprechen, folgt dann der URI aus dem Location-Header des 302 Redirects und führt einen "normalen" GET-Request auf diese TAPI-URI aus, bei dem die gleichen Request-Header aus dem vorherigen POST-Request (executeTrade) mitgeschickt werden. Der Signatur-Header ist allerdings zu diesem GET-Request nicht mehr valide, weil die URI per GET aufgerufen wurde und die übermittelte Signatur für eine POST-URI generiert wurde.
Somit liefert unser TAPI-Server für den GET-Request einen HTTP-Status 400 mit der Meldung "Invalid signature" zurück.
Ihre HTTP-Bibliothek, die dem 302-Response gefolgt ist, wird für die ursprüngliche Anfrage (POST-Request executeTrade) einfach den letzten HTTP-Response unseres Server auswerten und somit sieht es für Sie aus, als wäre dier ursprüngliche POST-Request mit einem 400 HTTP-Status-Code von uns quittiert worden.
 
Unsere Technik hat bereits den Fix eingespielt, welcher in dem oben beschriebenen Fall anstelle eines 302 nun einen 422 HTTP-Status-Code zurückliefert.
 
Sie müssten jetzt in Ihrem Bot einmal nachschauen, ob das Folgen des Location-Headers bei einem 30x-Redirect von Ihnen gewollt ist oder ob dieses Verhalten Standard bei Ihrer HTTP-Bibliothek ist.
Es wäre somit für Sie besser, wenn Sie NICHT automatisch der URI des Location-Headers folgen, sondern den nötigen GET-Request mit der validen Signatur "wie üblich" (lt. TAPI-Dokumentation ) durchführen.

 

  • Thanks 1
  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.