php curl

Fragen und Antworten
1

Hallo Team,

ich habe hier eine Struktur per API zu übermitteln und komme nicht dahinter, wie ich das in einen UrlDownload-Step bekomme. Als Basis habe ich ein php-Script, in welchem zuerst eine Variable erzeugt wird, die die zu übermittelnden Daten in einer XML-Struktur beinhaltet. Dann wird ein Array erzeugt, das diverse Felder beinhaltet und auch die xml-Variable referenziert und dann Base64 encoded. Das Ganze sieht so aus:


// Prepare XML data
$xml_data = '<?xml version="1.0" encoding="UTF-8"?>
<import version="1">
<order id="123" date="2015-02-01T12:34:56">
...
</order>
</import>';

// Setup
$url = 'https://.../api/import/';
$post_data = array(
'token' => 'c0JmAKCXig0MzkDE', // <- place your individual token here!
'version' => '1',
'type' => 'xml',
'load' => base64_encode($xml_data),
);

// Start cURL session
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_POST, true);
curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($curl, CURLINFO_HEADER_OUT, true);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_BINARYTRANSFER, true);

$post_result = curl_exec($curl);

curl_close($curl);


Das System erfordert es, daß alle vier Parameter (token, version, type und load) gefüllt/übermittelt werden. Wie kann ich das umsetzen?


Danke und Gruß,

Micha

2

Das sieht irgendwie nach HTTP Multipart-Request aus. Dort kann man quasi Formularparameter einzeln angeben.

3

Ich habe das jetzt mit dem Multipart aufgebaut. Jetzt gibt es noch ein Problem: Die Gegenstelle akzeptiert lediglich UTF-8-Codierung. Im Dropdown für den bodyContentType gibt es aber nur

multipart/form-data; charset=ISO-8859-1

Dementsprechend bekomme ich auch einen Error:

{"code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}}

Könnt ihr bitte ermöglichen, das Ganze in UTF-8 zu übermitteln?


Gruß Micha

4

bodyContentType sollte eine Combox sein. Du kannst da reinschreiben was du willst. Ändere das einfach ab wie du es brauchst.

5

Klappt aber nicht - wenn ich da

multipart/form-data; charset=UTF-8

reinschreibe, bekomme ich trotzdem

{"code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}}

Es wird also offenbar kein UTF-8 übertragen

6

Hmm wir schauen uns das an.

7

Vielleicht noch eine Zusatzinfo - Ausgangstext ist eine XML-Struktur, die aber als UTF-8 definiert ist, also


<?xml version="1.0" encoding="UTF-8"?>...

Die wird dann Base64-encodet, und dieser String wird dann übermittelt.


Gruß Micha

8

Kannst du bitte auch noch mal rein kopieren, was genau bei bodyContentType bei dir drin steht?

Damit können wir mal testen, ob evtl. dieser Inhalt nicht korrekt geparst wird.

9

Wir haben noch eine Stelle, wo das Charset nicht korrekt weitergegeben wurde und somit immer ISO-8859-1 genommen wurde.

Ein Fix ist in Arbeit.

10

Ja genau, der type application/x-www-form-urlencoded; charset=UTF-8 übermittelt auch ISO-8859-1. Wenn ich den ganzen Post Call so mit POSTMAN absetze, klappt alles, es liegt also eindeutig am falschen Parsing

11

Der Fix ist fertig gestellt und wird mit dem nächsten Deployment verteilt. Wir sagen nochmal Bescheid.

12

Hallo Micha,


der Fix ist jetzt auf den Servern verteilt.


Viele Grüße

Torsten

13

Hmm, also mit

application/x-www-form-urlencoded; charset=UTF-8

erhalte ich immer noch dieselbe Meldung:

{"code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}}


Ich probiere es noch mit multipart/form-data; charset=UTF-8

...

Leider auch: {"code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}}

14

Du musst unbedingt multipart/form-data; charset=UTF-8 nehmen. Ansonsten erkennen wir es nicht als Multipart und dann funktioniert das ganze mit den Key=Value Formularfeldern nicht.


Also wir haben wie folgt getestet um den Bug sichtbar zu machen:

Wir haben den Request an http://requestbin.net/ geschickt (also dort mal so ein private bin erstellen und dorthin POSTen)..


Nach unserem Fix sah es so aus: Es wurde UTF-8 übermittelt.



Vor unserem Fix stand da immer ISO-XXX, egal was du angegeben hast... also so wie du es berichtet hast.


Kannst du das auch mal gegen requestbin schicken und uns das Ergebnis inklusive deiner exakten APICAll Konfiguration schicken?

Am besten auch im Vergleich mit deinem POSTMan.


Wir müssen mal rausfinden, an welcher Stelle jetzt noch ISO-XXX übermittelt wird, so dass sich deine API beschwert.




15

Hallo Torsten,


das mit dem Requestbin hat so irgendwie nicht geklappt. Falls das tatsächlich nötig ist, arbeite ich mich da noch rein, aber nach meinem Verständnis müßtet ihr doch auch auf die Lösung kommen können, wenn ihr das hhtpLog des UrlDownload-Calls mit dem Code von Postman vergleicht, oder? Ich habe beides angehängt.

16

Danke die Logs sind auch hilfreich. Requestbin ist halt eine schicke Möglichkeit einen Request sichtbar zu machen, was wirklich auf der Gegenseite ankommt.


Was schon auffällt:


POSTMAN: schickt multipart, aber kein Charset.


Content-Type: multipart/form-data; boundary=.....


Synesty schickt charset=UTF-8

Content-Type: multipart/form-data; boundary=R-6UPJjM96MytJ5V0txdYqftyyCDAxVristpnTCc; charset=UTF-8


(das boundary-Zeug kommt automatisch dazu...)


Hast du bei Synesty schonmal versucht das charset wegzulassen?


also nur multipart/form-data; bei bodyContentType?

17

Gerade probiert, derselbe Mißerfolg

18

Hast du davon auch noch mal einen Log?

19

Ja, s. Anhang

20

Danke. Wir schauen uns das im Detail an.

Hier nur kurz:


Du kannst gern auch nochmal im Texteditor beide Requests nebeneinander legen. ISO-8859-1 wird von uns nirgends mitgeschickt. Uns ist schleierhaft, warum die API den Fehler {code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}} wirft.


Auffällig ist, dass POSTMan einige HTTP-Header weglässt wie z.B. Accept-Encoding (was du uns leer übermittelt wird). Vielleicht stört sich die API daran.


Evtl. kannst du mal bei den requestHeaders folgendes Accept-Encoding=application/json; charset=utf-8 mitgeben.
(Zumindest scheint deren API mit Content-Type: application/json; charset=utf-8 zu antworten)


1. Hast du eine Doku der API, wo das grob steht, was die alles im Request erwarten?

2. Hast du zufällig auch ein log von der PostMan Response?

3. Kannst du bei Postman mal versuchen "Accept-Encoding:" (also leer) mitzugeben und schauen, ob der Fehler kommt? Evtl. stört sich die API an irgendeinem header, den wir zusätzlich mitschicken wie z.B. User-Agent.