TRestClient UploadFile vs PHP

[gmc616]

Hallo Uwe.
Ja, der Code ist verworren. Wie gesagt, ist quasi ein Bastel-Code, mit dem ich schon ne Menge rumprobiert habe.

Ich habe deinen Code jetzt entsprechend eingebaut, funktioniert leider auch nicht.
Die ersten Zeilen habe ich allerdings ausgetauscht, da der Upload (ähnlich wie hier, auch per TOAuth2Authenticator) funktionieren soll.

Delphi-Quellcode:

  
  {...}
  FRESTClient.BaseURL := 'http://myServer.tld/API.php';
  try
    request := TRESTRequest.Create(FRESTClient); // spart das try-finally-Free
    request.Client := FRESTClient;
    request.Method := rmPOST;
  {...}

Alle Parameter kommen Server-seitig an. Auch der volle Dateiname.
Nur ist das PHP-seitige $_FILES immernoch leer.
request.Response.Status.Success ist TRUE, war aber zu erwarten, wenn ich dem Server-seitigen Entwickler glauben darf.

Ich glaube auf diese Art hatte ich es auch schon probiert.
Damals hatte ich Fiddler mitlaufen lassen, um herauszufinden, was unterschiedlich ist, in dem was Delphi und das Javascript an den Server sendet.
Ich habe die Request-Header vergleichen, die waren nahezu identisch, zumindest in dem was ich für wichtig halte. In den Raw-Daten konnte ich auch meine Datei "sehen".
Die Datei geht also rüber zum Server. Auch beim Debuggen merkt man an der kurzen Verzögerung, dass da richtig was passiert.
Aber der Server scheint die Datei nicht entgegen zu nehmen. ... per JavaScript gehts

OT:
Blöder weise entwickelt sich diese Bastel-Funktion mittler Weile von einem "NiceToHave" zu einem "MustHave".
Ich habe gestern eine Anfrage bekommen, ob ich mittels REST-API XML-Daten austauschen kann.

"Na klar kann ich das ..."
Leider ist aus der Doku nicht erkennbar, ob der Server XML-Daten oder XML-Dateien erwartet. Die Doku spricht von Dateien, zeigt aber nur XML-Daten. Aber das kommt später.
Das ganze läuft dort über eine Basic Authentication, die in meinem Code schon weitestgehend funktioniert und ich deswegen den Upload (und den Download) an meinen vorhanden FRESTClient gebunden haben möchte, sollte das Ganze tatsächlich über XML-Dateien laufen sollen.

[Uwe Raabe]

Zitat von gmc616:

Damals hatte ich Fiddler mitlaufen lassen, um herauszufinden, was unterschiedlich ist, in dem was Delphi und das Javascript an den Server sendet.
Ich habe die Request-Header vergleichen, die waren nahezu identisch, zumindest in dem was ich für wichtig halte.

Kannst du das nochmal machen und mir die entsprechenden Protokolle zukommen lassen?

[gmc616]

Delphi, mit dem aktuelle Code von oben.

Code:

POST http://myServer.tld/API.php?action=uploadfile&iddatei=3048&version=1.0.0.5&filename=1466060264095.jpg HTTP/1.1
Connection: Keep-Alive
Content-Type: multipart/form-data; boundary=-------Embt-Boundary--7C912B623C4CE4EF
Accept: application/json, text/plain; q=0.9, text/html;q=0.8,
Accept-Charset: utf-8, *;q=0.8
User-Agent: Embarcadero RESTClient/1.0
Content-Length: 915233
Host: myServer.tld

-----------Embt-Boundary--7C912B623C4CE4EF
Content-Disposition: form-data; name="file"; filename="1466060264095.jpg"
Content-Type: image/jpeg

�����JFIF

{ ... das JPG, wird hier im Forum umcodiert ... }

---------Embt-Boundary--7C912B623C4CE4EF--

JavaScript

Code:

POST http://myServer.tld/API.php?action=uploadfile&iddatei=3048&version=1.0.0.1&filename=1466060264095.jpg HTTP/1.1
Host: myServer.tld
Connection: keep-alive
Content-Length: 915231
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7v1duMCECzltfN0g
Accept: */*
Origin: null
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7

------WebKitFormBoundary7v1duMCECzltfN0g
Content-Disposition: form-data; name="file"; filename="1466060264095.jpg"
Content-Type: image/jpeg

�����JFIF

{... das gleiche JPG ...}
------WebKitFormBoundary7v1duMCECzltfN0g--

Ich sehe grad, dass die "version" ist der POST-URL unterschiedlich sind, das ist aber nicht der ausschlaggebende Punkt.

[Uwe Raabe]

Als erstes fällt der Unterschied im version-Parameter auf. Aber das hast du ja schon geklärt.

Die Differenz bei der Content-Length liegt an der unterschiedlichen Länge der ersten Boundary. Keine Ahnung ob das relevant ist.

Die Unterschiede in den verschiedenen Accept-Headern sollten nicht relevant sein, da es dabei nur um die Antwort geht. Im Zweifel kannst du die ja auch mal entsprechend belegen.

Den User-Agent kannst du ja auch mal probeweise anpassen.

Ansonsten: Mit PHP habe ich nicht so wirklich was am Hut. Da kann ich nicht weiter helfen.

[gmc616]

Wie gesagt: Auch für mich sehen die Request-Header quasi identisch aus.
Deswegen auch der verworrene Bastel-Code im #3.

Also könnte man sagen: Der Fehler ist eher auf der Server-Seite zu suchen?

Mit PHP habe ich auch schon seit PHP-4 nichts mehr am Hut.
Hatte damals mit der Umstellung von PHP-3 auf PHP-4 auf einem Gentoo-Linux ausreichend Probleme, um der ganzen Geschichte Adieu zu sagen^^

Aber ist mein Ansatz, mein Gedanke, in #5 korrekt? Macht man das so?
Oder fällt mir das Ganze wieder auf die Füße, wenn mir irgendwann eine neue Authentication-Methode über den Weg läuft?

Uwe, ich danke Dir trotzdem für dein Bemühen.

[Uwe Raabe]

Zitat von gmc616:

Aber ist mein Ansatz, mein Gedanke, in #5 korrekt? Macht man das so?
Oder fällt mir das Ganze wieder auf die Füße, wenn mir irgendwann eine neue Authentication-Methode über den Weg läuft?

Prinzipiell sollte das gehen. Natürlich sind auch in den Delphi-Komponenten Fehler nicht auszuschließen (sind sie definitiv nicht). Allerdings gilt das vermutlich auch für andere Bibliotheken. Man muss sowas dann halt analysieren und melden, damit es auch besser werden kann. Gegen eine zickige Server-Programmierung kann man natürlich nur wenig machen.

[Olli73]

Da in dem Javascript für den Feldnamen des "Dateifeldes" explizit "file" angegeben ist, würde ich mal folgende Zeile anpassen:

request.AddFile('file', filename);
Edit: Sieht aber so aus, als ob er bei beiden schon Name="file" setzt...