Es wird entweder nicht gesendet oder nicht richtig empfangen. @ Verwendcurl direkt von der Befehlszeile (mit der Option -d) oder von PHP (mit CURLOPT_POSTFIELDS) funktioniert.

Ich beginne mit einer PSR-7-Anfrage:

$request = GuzzleHttp\Psr7\Request('POST', $url);

Ich füge einen Authentifizierungsheader hinzu, der sich korrekt gegenüber der API authentifiziert:

$request = $request->withHeader('Authorization', 'Bearer ' . $accessToken);

Dann füge ich den Anfragetext hinzu:

// The parameter for the API function
$body = \GuzzleHttp\Psr7\stream_for('args=dot');
$request = $request->withBody($body);

Ich kann die Nachricht an die API senden:

$client = new \GuzzleHttp\Client();
$response = $client->send($request, ['timeout' => 2]);

Die Antwort, die ich zurück bekomme, zeigt an, dass der Parameter "args" von der API einfach nicht gesehen wurde. Ich habe versucht, das Authentifizierungstoken in die Argumente zu verschieben:

'args=dot&access_token=123456789'

Dies sollte funktionieren, und does Mit Locken von der Kommandozeile aus arbeiten -d access_token=123456789), aber die API kann diesen Parameter auch beim Senden von cia curl (6.x) nicht sehen.

Ich kann die Nachricht sehen does enthält den Körper:

var_dump((string)$request->getBody());
// string(8) "args=dot"
// The "=" is NOT URL-encoded in any way.

So was könnte hier schief gehen? Werden die Parameter nicht gesendet oder werden sie im falschen Format gesendet (möglicherweise wird '=' codiert?) Oder wird möglicherweise der falsche Inhaltstyp verwendet? Es ist schwierig zu erkennen, was "auf dem Draht" gesendet wird, wenn Guzzle verwendet wird, da die HTTP-Nachricht formatiert und vielschichtig gesendet wird.

Edit: Aufrufen eines lokales Testskript Anstelle der Remote-API erhalte ich die folgende Rohnachricht:

POST
CONNECTION: close
CONTENT-LENGTH: 62
HOST: acadweb.co.uk
USER-AGENT: GuzzleHttp/6.1.1 curl/7.19.7 PHP/5.5.9

args=dot&access_token=5e09d638965288937dfa0ca36366c9f8a44d4f3e

So sieht es aus wie der Körper ist gesendet wird, also fehlt vermutlich noch etwas, um der Remote-API mitzuteilen, wie dieser Text zu interpretieren ist.

Edit: Die an dasselbe Testskript gesendete Befehlszeilenlocke gibt mir zwei zusätzliche Headerfelder in der Anforderung:

CONTENT-TYPE: application/x-www-form-urlencoded
ACCEPT: */*

Ich gehe davon aus, dass der Inhaltstyp-Header, der in der Guzzle-Anforderung fehlt, die Ursache des Problems ist. Also ist das ein Guzzle-Bug? Sollte es nicht immer einen Content-Type senden, basierend auf den Annahmen, die es macht, dass sind in der Dokumentation aufgeführt?