Question Comment afficher les données POST avec cURL?


À titre d'exemple, POST sur un serveur Web avec l'argument -v:

curl -v http://testserver.com/post -d "firstname=john&lastname=doe"

Et la sortie

> POST /post HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> Host: testserver.com
> Accept: */*
> Content-Length: 28
> Content-Type: application/x-www-form-urlencoded
> 
< HTTP/1.1 200 OK
(etc)

Il n'y a aucune mention des données que j'ai publiées.

Existe-t-il une option dans cURL pour afficher la chaîne "firstname = john & lastname = doe" dans la sortie?

Note: Évidemment, la chaîne que je veux est dans la commande que j'ai exécutée, mais il existe plusieurs autres options de publication telles que --form et --data-ascii, etc. J'aimerais voir les données brutes envoyées au serveur.


110
2018-06-01 09:10


origine


Vous pouvez également exécuter tcpdump pour capturer les données réelles envoyées au serveur. Ou wireshark (mieux) si vous avez ça. - Keith
Je ne suis pas sûr que tu le peux. Est-ce un exemple de sécurité par l'obscurité? - stackoverflow.com/questions/198462/... - slotishtype


Réponses:


Le plus proche que j'ai eu sans utiliser tcpdump utilise le --trace-ascii option:

~ curl http://w3.org/ -d "hello=there" --trace-ascii /dev/stdout
== Info: About to connect() to w3.org port 80 (#0)
== Info:   Trying 128.30.52.45... == Info: connected
== Info: Connected to w3.org (128.30.52.45) port 80 (#0)
=> Send header, 210 bytes (0xd2)
0000: POST / HTTP/1.1
0011: User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.1
0051: 9.7 OpenSSL/0.9.8l zlib/1.2.3
0070: Host: w3.org
007e: Accept: */*
008b: Content-Length: 11
009f: Content-Type: application/x-www-form-urlencoded
00d0: 
=> Send data, 11 bytes (0xb)
0000: hello=there

Malheureusement, cela ne fonctionne pas lorsque vous publiez multipart/form-data:

~ curl http://w3.org/ -F hello=there -F testing=123 --trace-ascii /dev/stdout
== Info: About to connect() to w3.org port 80 (#0)
== Info:   Trying 128.30.52.45... == Info: connected
== Info: Connected to w3.org (128.30.52.45) port 80 (#0)
=> Send header, 270 bytes (0x10e)
0000: POST / HTTP/1.1
0011: User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.1
0051: 9.7 OpenSSL/0.9.8l zlib/1.2.3
0070: Host: w3.org
007e: Accept: */*
008b: Content-Length: 244
00a0: Expect: 100-continue
00b6: Content-Type: multipart/form-data; boundary=--------------------
00f6: --------19319e4d1b79
010c: 
<= Recv header, 32 bytes (0x20)
0000: HTTP/1.1 301 Moved Permanently

139
2018-06-01 10:50



Je sais que c'est votre propre réponse, mais je pense que vous pouvez accepter cela comme la bonne réponse. Ca a résolu pour moi quand même, merci :-) - Darren Cook
Supprimer tout -v ou --verbose comme ils remplacent la directive de trace. - AlikElzin-kilaka
@AugustinRiedinger Cela fonctionne bien avec https. Je viens de l'essayer et j'ai vu la charge utile. Les données sont cryptées, mais comme vous êtes le point d'extrémité de la connexion, vous disposez de toutes les données et Curl peut donc les voir. - Gerald Kaszuba
En utilisant --trace-ascii a travaillé pour moi sur OS X 10.8.5 Mountain Lion. J'ai téléchargé une entité de forme multi-parties avec deux images et un corps json et tout fonctionnait comme prévu - Heath Borders
Au lieu de --trace-ascii /dev/stdout vous pouvez --trace-ascii - (tiret) - Adam Michalik


Ou vous pourriez tester avec https://httpbin.org/

$ curl https://httpbin.org/post -d "firstname=john&lastname=doe"
{
  "args": {}, 
  "data": "", 
  "files": {}, 
  "form": {
    "firstname": "john", 
    "lastname": "doe"
  }, 
  "headers": {
    "Accept": "*/*", 
    "Content-Length": "27", 
    "Content-Type": "application/x-www-form-urlencoded", 
    "Host": "httpbin.org", 
    "User-Agent": "curl/7.43.0"
  }, 
  "json": null, 
  "origin": "78.228.163.126", 
  "url": "https://httpbin.org/post"
}

16
2017-09-30 09:21





Vous pourriez utiliser Charles et curl --proxy localhost:8888. Simples!


7
2017-08-28 13:51



non, cela ne fonctionne pas avec https. La réponse acceptée est bien et plus facile. - akostadinov
https n'était pas une exigence dans la question: p - Dori
@CasparHarmer quel est votre problème avec la réponse acceptée? Si vous avez besoin de plus, TCPdump fait l'affaire. - Gewure
Cela s'est passé il y a 3 ans. Je me rappelle plus. - Caspar Harmer


Voudrais ajouter une alternative à netcat

#!/bin/bash
nc -l 8080 &

curl "http://localhost:8080" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
--data @<(cat <<EOF
{
  "me": "$USER",
  "something": $(date +%s)
}
EOF
)

7
2018-05-21 13:04