¿Cómo mostrar los datos POST con cURL?


140

Como ejemplo, PUBLICANDO en un servidor web con el argumento -v:

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

Y la salida

> 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)

No se menciona la información que publiqué.

¿Hay una opción en cURL para mostrar la cadena "firstname = john & lastname = doe" en la salida?

Nota: Obviamente, la cadena que quiero está en el comando que ejecuté, pero hay varias otras opciones de publicación como --form y --data-ascii, etc. Me gustaría ver los datos sin procesar que se envían al servidor.


1
También puede ejecutar tcpdump para capturar los datos reales que se envían al servidor. O wireshark (mejor) si tienes eso.
Keith

No estoy seguro de que puedas. ¿Es este un ejemplo de seguridad por oscuridad? - stackoverflow.com/questions/198462/…
slotishtype

Respuestas:


176

Lo más cercano que obtuve sin usar tcpdumpes usar la --trace-asciiopción:

~ 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

Desafortunadamente, esto no funciona cuando publicas 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

44
Sé que es tu propia respuesta, pero creo que puedes aceptarla como la respuesta correcta. Lo resolvió para mí de todos modos, gracias :-)
Darren Cook

44
Elimine cualquiera -vo, --verboseya que anulan la directiva de rastreo.
AlikElzin-kilaka

2
@AugustinRiedinger Funciona bien con https. Lo intenté y vi la carga útil. Los datos están encriptados, pero como usted es el punto final de la conexión, tiene todos los datos disponibles y, por lo tanto, curl puede verlos.
gak

2
El uso --trace-asciifuncionó para mí en OS X 10.8.5 Mountain Lion. He subido una entidad de formulario multiparte con dos imágenes y un cuerpo json y todo funcionó como se esperaba
Heath Borders

44
En lugar de --trace-ascii /dev/stdoutque puedas --trace-ascii -(guión)
Adam Michalik

27

O podrías probar con 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"
}

12

Me gustaría agregar la alternativa 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
)

9

Podrías usar Charles y curl --proxy localhost:8888. Simples!


44
no, no funciona con https. La respuesta aceptada está bien y es más fácil.
akostadinov

httpsno era un requisito en la pregunta: p
Dori

@CasparHarmer, ¿cuál es tu problema con la respuesta aceptada? Si necesita más, TCPdump hace el trato.
Gewure

Esto sucedió hace 3 años. No puedo recordar.
Caspar Harmer
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.