Neues Thema starten

php curl

 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


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

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

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

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

Hmm wir schauen uns das an. 

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

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. 

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. 

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

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

Hallo Micha, 


der Fix ist jetzt auf den Servern verteilt.


Viele Grüße

Torsten

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"}}

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.




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.

txt
(3.46 KB)
log
Anmelden um einen Kommentar zu veröffentlichen