TRestClient UploadFile vs PHP

[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...