TRESTClient - POST ohne Content-Type

[Neutral General]

Hallo,

Ich bin gerade am verzweifeln. Ich muss ein POST ausführen, aber sende mit dem POST keine Daten.
Daher übergebe ich keinen Content-Type, denn der Server will in diesem Fall auch keinen Content-Type.
TRESTClient bzw. TRESTRequest fällt aber dann jedes mal auf 'application/x-www-form-urlencoded' (TRESTContentType.ctAPPLICATION_X_WWW_FORM_URLENCO DED) zurück.
Und nachdem ich mir den Code etwas angeschaut habe, sieht es tatsächlich so aus als wäre es unmöglich bei einem POST keinen Content-Type mitzuschicken

Kann das sein? Gibt es da irgendeinen Trick?
Das hält mich jetzt schon deutlich länger auf als es sollte

[mjustin]

Nach RFC 7231 darf man den Content-Type leer lassen:

Zitat:

A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream"
([RFC2046], Section 4.5.1) or examine the data to determine its type.

Wenn der Server dagegen auf einem Content-Type besteht, ist das eigentlich nicht konform, sondern eine Eigenwilligkeit des Web Service.

Ich würde es als Bug in TRESTClient melden. Workarounds sind schwierig, falls Delphi keinen Interceptor (etwas zum Nachbearbeiten des Requests) bietet.
Man könnte den Delphi - Quelltext anpassen...

[Bbommel]

Ja, der RestClient bzw. RestRequest sind etwas eigenwillig, was den ContentType angeht. Da wirst du tatsächlich kaum eine Chance haben, da Delphi meint, es besser zu wissen als der Nutzer und den Content-Type zur Not selber setzt. Man kann auch keinen Content-Type setzen, der von der fest in Delphi hinterlegten Liste abweicht. Ich hatte dazu auch schon mal ein Ticket aufgemacht, was ja vom Prinzip her in eine ähnliche Richtung geht wie dein Anliegen jetzt:
https://quality.embarcadero.com/browse/RSP-19793

Wahrscheinlich kommst du dann mit TidHHTP und "selber machen" schneller zum Ziel (habe ich selber aber bisher nicht getestet).

[Neutral General]

@mjustin: Der Server besteht nicht auf einen Content-Type. Er will entweder einen der unterstützt wird oder gar keinen (falls keiner notwendig ist).

Ich hab in diesem Fall Glück, denn der REST-Server ist mein eigener.
Wenn ich im Client also explizit einen (gültigen) Content-Type Header hinzufüge, wenn ich keinen Content mitschicke, dann funktioniert es auch und mein Server ist glücklich.
Habe euch das mit dem Server allerdings erst vorenthalten, weil ich Antworten wie "Dann änder deinen Server" vermeiden wollte.
Weil das in meinen Augen kein Problem des Servers, sondern der RESTClient Klassen von Delphi ist.

[Codehunter]

Wegen genau solcher Probleme, mangelnder Flexibilität und Dauerstress bzgl. TLS 1.2 habe ich die REST-Komponenten von Delphi für mich wieder beerdigt und bin zurück auf die klassische Indy & JSONObject-Kombination. Seither ruhiges Leben an der Front.

Nachtrag Wobei meine Programme mit vielen verschiedenen Servern sprechen müssen. Davon habe ich keinen unter meiner eigenen Kontrolle. Ihr glaubt gar nicht was einem da alles an Non-Standard-REST begegnet. Mit den REST-Komponenten musste ich ganze Kaskaden von try-except-on-do-Blöcken bauen. Emba täte gut daran, die REST-Komponenten wieder von OS-native (WinInet etc.) zurück auf Indy zu migrieren. So wie es früher war.

[Bbommel]

Aber hast du mit Indy nicht eigentlich genauso Stress (nur halt an einer anderen Baustelle), weil du immer die aktuelle openssl-Bibliothek mitliefern musst?

[Codehunter]

Zitat von Bbommel:

Aber hast du mit Indy nicht eigentlich genauso Stress (nur halt an einer anderen Baustelle), weil du immer die aktuelle openssl-Bibliothek mitliefern musst?

Im Gegenteil! Die legen wir einfach dem Setup bei. So haben wir immer Gewissheit dass unsere Nutzer auf dem selben Stand sind wie wir Entwickler. Bei OS-native hatten wir oft das Problem, dass die Zielrechner auf einem unterschiedlichen Patch-Stand waren oder Microsoft grade mal wieder irgendwas kaputtgepatched hatte und bei uns die Telefone heiß liefen. Die Notwendigkeit, OpenSSL zu tauschen ergibt sich auch nicht gar so oft wie man denkt. Unsere Software ist ja kein Webbrowser, der mit undenklich vielen verschiedenen Webservern klar kommen muss. Die Anzahl der Extrawürste seitens REST-Server ist überschaubar. Warum also OpenSSL upgraden, wenn sich auf keinem unserer Peers etwas an den Stromchiffren etc. verändert hat?

[Neutral General]

Also ich habe mit den REST-Komponenten auch schon fremde APIs angesprochen und das bisher ohne Probleme.
Und mit meinen bisherigen Erfahrungen der letzten 10-15 Jahre haben mir die Indys deutlich mehr Ärger gemacht als die neuen nativen HTTP-Komponenten.

Wobei man natürlich gerade an dem Fall sieht, dass auch die noch ihre Macken haben.
Würde allerdings trotzdem jederzeit eher TRESTClient/THTTPClient nutzen als Indys, falls möglich.

[mjustin]

Zitat von Neutral General:

@mjustin: Der Server besteht nicht auf einen Content-Type. Er will entweder einen der unterstützt wird oder gar keinen (falls keiner notwendig ist).

Oha, da war ich beim Schreiben kurzzeitig ganz woanders, dieser Teil meiner Antwort kann gelöscht werden