curl-Befehlsgenerator
Erstellen Sie aus HTTP-Methode, URL, Headern, Body und Authentifizierungsoptionen einen echten, funktionierenden curl-Befehl — mit automatisch korrekt angewendeter Shell-Maskierung — und kopieren Sie ihn mit einem Klick.
234 Aufrufe
Eine kurze Geschichte von curl
curl wurde 1998 vom schwedischen Entwickler Daniel Stenberg geschaffen, der die erste Version schrieb, um automatisch Wechselkurse für einen IRC-Bot in einem schwedischen Chatkanal abzurufen — ein kleines, persönliches Bedürfnis, kein großer Plan, Infrastruktur zu bauen. Immer mehr Leute wünschten sich weitere Protokolle und Optionen, und aus dem kleinen Werkzeug wurde ein universelles Kommandozeilen-Tool zur Datenübertragung über HTTP, HTTPS, FTP und mit der Zeit Dutzende weitere Protokolle. Stenberg ist seither praktisch die gesamte Lebenszeit von curl hindurch dessen Hauptbetreuer geblieben; heute ist curl standardmäßig auf macOS, so gut wie jeder Linux-Distribution und — seit 2018 — auf Windows 10 und neueren Versionen vorinstalliert, und es wird geschätzt, dass es auf Milliarden von Geräten weltweit läuft, von Routern und Autos bis hin zu Spielkonsolen und nahezu jeder Continuous-Integration-Pipeline, die mit einer API spricht. Was als Lösung für ein einziges, eng begrenztes persönliches Problem begann, ist heute wohl der am weitesten verbreitete Kommandozeilen-HTTP-Client überhaupt und eine der Open-Source-Komponenten, auf die sich das Internet still und heimlich am stärksten verlässt.
Die von diesem Tool erzeugten Flags verstehen
Standardmäßig folgt curl keinen HTTP-Weiterleitungen. Antwortet ein Server mit dem Statuscode 301 oder 302 und einem Location-Header, der auf eine andere Adresse verweist, gibt einfaches curl diese Weiterleitungsantwort — oder einen leeren Inhalt — aus und hört auf; es verfolgt die neue URL nicht automatisch, wie es ein Webbrowser stillschweigend tut. Das bringt eine enorme Zahl von curl-Einsteigern durcheinander: Eine URL, die im Browser einwandfrei funktioniert, liefert bei curl scheinbar grundlos eine verwirrende, leere oder falsche Antwort — einfach weil der Browser einer Weiterleitung gefolgt ist, der curl nicht gefolgt ist. Die Lösung ist das Flag -L (--location), das curl anweist, der Weiterleitungskette bis zu ihrem endgültigen Ziel zu folgen. Es ist ein derart häufiger Bedarf, dass viele Entwickler -L standardmäßig verwenden, außer wenn sie gezielt das Weiterleitungsverhalten selbst testen wollen.
Sobald ein Befehl Header oder Body-Inhalte mit Leerzeichen, Anführungszeichen oder shell-spezifischen Zeichen ($, &, ;, Backticks) enthält, ist die Art der Anführung keine Kosmetik mehr — sie entscheidet, ob eine Anfrage funktioniert oder von der Shell verstümmelt wird, bevor curl sie überhaupt zu Gesicht bekommt. Ein Header wie Authorization: Bearer abc 123, ohne Anführungszeichen eingegeben, wird von der Shell am Leerzeichen aufgeteilt, sodass curl Authorization: und Bearer als zwei getrennte, kaputte Argumente statt eines einzigen erhält. Den gesamten Wert in einfache Anführungszeichen zu setzen weist die Shell an, alles darin wörtlich zu behandeln, Leerzeichen eingeschlossen — allerdings können einfache Anführungszeichen selbst kein wörtliches einfaches Anführungszeichen enthalten, da genau dieses Zeichen die Anführung beendet. Die Standardlösung dafür besteht darin, die Anführung zu schließen, ein mit Backslash maskiertes einfaches Anführungszeichen einzufügen und die Anführung wieder zu öffnen: '\''. Dieses Tool wendet diese Maskierung automatisch auf jeden eingefügten Wert an, sodass Header, Body-Inhalte und Zugangsdaten mit Leerzeichen, Anführungszeichen oder anderen Sonderzeichen stets einen korrekt lauffähigen Befehl ergeben — ohne dass Sie sich die Maskierungsregeln selbst merken müssen.
Häufig gestellte Fragen
Warum brauche ich bei manchen curl-Befehlen das Flag -L?
curl folgt HTTP-Weiterleitungen standardmäßig nicht. Antwortet der aufgerufene Server mit dem Statuscode 301 oder 302 und einem Location-Header, zeigt einfaches curl statt des endgültigen Inhalts nur diese Weiterleitungsantwort an und hört dort auf. Browser folgen Weiterleitungen stillschweigend, weshalb eine URL, die "im Browser funktioniert", bei curl eine leere oder unerwartete Antwort liefern kann. Das Hinzufügen von -L (--location) weist curl an, der Weiterleitungskette automatisch bis zum endgültigen Ziel zu folgen.
Warum schlägt mein curl-Befehl fehl, wenn ein Header ein Leerzeichen enthält?
Nicht curl, sondern die Shell teilt eine Befehlszeile in einzelne Argumente auf, und sie tut das standardmäßig an nicht in Anführungszeichen stehenden Leerzeichen. Ein Header-Wert wie Bearer abc123, ohne Anführungszeichen eingegeben, wird zu zwei getrennten Wörtern, die die Shell curl so übergibt, als wären es zwei verschiedene Argumente — der Header wird dadurch zerstört. Den Wert in einfache Anführungszeichen zu setzen sagt der Shell "behandle alles darin als ein einziges wörtliches Stück, Leerzeichen eingeschlossen" — genau das tut dieses Tool automatisch für jedes von Ihnen ausgefüllte Feld.
Was ist der Unterschied zwischen JSON-Modus und Raw-Modus für den Request-Body?
Der JSON-Modus fügt automatisch einen Header Content-Type: application/json zu Ihrem Body hinzu und teilt dem Server mit, die Nutzdaten als JSON zu interpretieren — die meisten modernen APIs verlangen diesen Header zwingend, sonst weisen sie die Anfrage zurück oder deuten sie falsch. Der Raw-Modus sendet exakt den eingegebenen Text ohne angenommenen Content-Type — die richtige Wahl für formularkodierte Daten, reinen Text, XML oder jeden Body, bei dem Sie Ihren eigenen Content-Type-Header manuell über den Header-Bereich setzen möchten.
Ist die Bearer-Token-Authentifizierung dasselbe wie Basic-Auth?
Nein, beide funktionieren unterschiedlich. Bearer-Auth sendet einen Header Authorization: Bearer <token> mit einem undurchsichtigen Zugriffstoken, üblicherweise ausgestellt durch einen OAuth-Ablauf oder ein API-Schlüsselsystem — der Server schlägt das Token nach, statt es zu entschlüsseln. Basic-Auth sendet Authorization: Basic <base64(benutzername:passwort)>, also schlicht Ihren zusammengefügten und base64-kodierten Benutzernamen und Ihr Passwort — Kodierung ist keine Verschlüsselung, weshalb Basic-Auth ausschließlich über HTTPS verwendet werden darf, niemals über einfaches HTTP, sonst werden die Zugangsdaten faktisch im Klartext übertragen.
Wer hat curl entwickelt, und wird es noch aktiv gepflegt?
curl wurde 1998 von Daniel Stenberg geschaffen, ursprünglich um Wechselkurse für einen IRC-Bot abzurufen. Stenberg ist praktisch während der gesamten Geschichte von curl dessen Hauptbetreuer geblieben und entwickelt es bis heute aktiv weiter. Weit entfernt von einem Hobbyprojekt ist curl heute eine der am weitesten verbreiteten Softwarekomponenten der Welt — eingebettet in Betriebssysteme, eingebettete Geräte und unzählige Anwendungen — und seine Sicherheit und Korrektheit werden von einer großen Beitragenden-Community entsprechend ernst genommen.
Ähnliche Tools
Problem melden
curl-Befehlsgenerator
Kommentare
Noch keine Kommentare — schreiben Sie den ersten!