Httpie: Demande d'ajout de l'option `-d, --data` pour le corps brut comme curl

Quel est le problème avec l'ajout de l'option -d à http ?

Il n'y aurait rien de _particulièrement_ mal à cela. Je trouve juste que la tuyauterie est plus propre et je préfère fortement quand il n'y a qu'une seule façon de faire la même chose. La tuyauterie existe dans ce but précis (c'est-à-dire pour transmettre des _données_ aux programmes), et elle est facile à comprendre, universelle et sans ambiguïté. Chaque outil CLI décent prend en charge la tuyauterie (à l'exception notable de curl ), vous n'avez donc besoin d'apprendre le concept qu'une seule fois.

Comparer:

httpie

Une méthode universelle pour transmettre les données de requête consiste à rediriger stdin (entrée standard). Ces données sont mises en mémoire tampon, puis sans autre traitement utilisé comme corps de requête.

boucle

-d, --data <data>
              (HTTP)  Sends  the  specified data in a POST request to the HTTP server, in the same way that a browser
              does when a user has filled in an HTML form and presses the submit button. This will cause curl to pass
              the  data  to  the  server  using  the  content-type application/x-www-form-urlencoded.  Compare to -F,
              --form.

              -d, --data is the same as --data-ascii. --data-raw is almost the same  but  does  not  have  a  special
              interpretation of the @ character. To post data purely binary, you should instead use the --data-binary
              option.  To URL-encode the value of a form field you may use --data-urlencode.

              If any of these options is used more than once on the same command line, the data pieces specified will
              be merged together with a separating &-symbol. Thus, using '-d name=daniel -d skill=lousy' would gener-
              ate a post chunk that looks like 'name=daniel&skill=lousy'.

              If you start the data with the letter @, the rest should be a file name to read the data from, or -  if
              you  want  curl  to read the data from stdin. Multiple files can also be specified. Posting data from a
              file named 'foobar' would thus be done with --data @foobar. When --data is told to  read  from  a  file
              like  that,  carriage  returns  and newlines will be stripped out. If you don't want the @ character to
              have a special interpretation use --data-raw instead.

Oui, je suis d'accord avec vous que la prise en charge de la tuyauterie dans un outil de ligne de commande est une bonne fonctionnalité, et j'ai également créé un outil de ligne de commande qui prend en charge la tuyauterie ( Mongotail ), et pour être honnête, je ne savais pas que curl ne le supporte pas. Mais je pense que la prise en charge des deux fonctionnalités n'ajoute pas de complexité, car presque tous les outils CLI connus de l'écosystème Unix prennent en charge les deux sens. Par exemple. cat , grep , find , tail ...

Les commandes que vous mentionnez acceptent généralement soit une liste d'arguments de nom de fichier, soit des données d'entrée brutes via stdin . Cependant, ils n'acceptent pas les données réelles comme arguments. Accepter des données brutes via un argument est assez rare.

(Clarification de ce que j'ai écrit dans un commentaire précédent : curl prend en charge stdin mais il doit être explicitement demandé de le lire avec, par exemple, --data-binary @- .)

Je suis venu ici pour signaler un bogue lié à ce problème, alors peut-être que ce n'est pas un bogue mais qu'il fonctionne comme prévu.

J'ai un script bash que je changeais pour utiliser "httpie" au lieu de "curl". Les requêtes sont des POST vides vers un serveur http. J'exécute ce script en le canalisant dans un docker exec -i ${container} bash -x .

J'ai eu du mal à comprendre que la commande http POST , alors qu'elle fonctionnait correctement lorsqu'elle était exécutée à partir d'un shell interactif, provoquait la fermeture immédiate du script.

Je suppose que c'est quelque chose à propos http lire stdin dans le docker exec . Il semble étrange que je doive utiliser " echo -n " pour éviter cela.

#!/bin/bash
echo "STARTING..."
echo -n | http POST ...     # this replaces: curl -XPOST --data-binary '' ...
echo "Without the 'echo -n' above this statement would not be reached."
echo "DONE"

( @jamshid vous POST un corps vide simplement avec http POST httpbin.org/post . Veuillez lire les spécificités de l'utilisation de HTTPie dans le script - vous voulez inclure l'option --ignore-stdin . Ce n'est pas un problème lié , veuillez donc ouvrir un nouveau sujet au lieu de répondre ici, si nécessaire.)

Ai-je raison de penser que 15.1 Les données de demande d'un nom de fichier couvrent la demande d'origine de ce problème ? Je suppose que ce problème peut être clos.

En passant, j'aurais aimé connaître HTTPie avant-hier, car j'aurais évité environ 3 heures de comprendre pourquoi les sauts de ligne dans mon fichier XML n'étaient pas conservés. (Je pensais que c'était mon application mais c'était curl, ce qui nécessite que son option --data-binary soit utilisée pour laisser les données seules.) Merci pour HTTPie !

Ce n'est pas le cas, @DavidOliver . @mrsarm a demandé de pouvoir transmettre une chaîne de paramètre, pas le contenu d'un fichier.

+1

Accepteriez-vous MR avec cette fonctionnalité @jakubroztocil ?

vous pouvez simplement faire http POST example.org <<< "foo bar" ou http POST example.org < file.name

http :/api/hey say=Bonjour à=moi …

vous pouvez simplement faire http POST example.org <<< "foo bar" ou http POST example.org < file.name

ne semblait pas fonctionner pour powershell, 'raw body data' | http post :8080/api/events a fonctionné pour moi sur powershell,
mais je veux toujours -d, --data ou quelque chose comme ça pour transférer des données corporelles brutes

selon la documentation, vous pouvez utiliser une chaîne "Bash here":

http example.com/ <<<'{"name": "John"}'

Du point de vue de l'interface utilisateur, l'option a du sens.

Je n'arrive pas à trouver un moyen d'envoyer un objet json vide ( {} ) qui est un cas d'utilisation étrange mais valide.

@minusf : je n'arrive pas à trouver un moyen d'envoyer un objet json vide ( {} ) qui est un cas d'utilisation étrange mais valide.

$ echo '{}' | http httpbin.org/post

un moyen de supprimer la nouvelle ligne lors de la redirection ?

$ echo 20 | http POST httpbin.org/post

les données déposées seraient "data": "20\n"

@hahattan vous pouvez demander echo de ne pas imprimer le caractère de fin de ligne avec -n :

$ echo -n foo | http httpbin.org/post