当POST从http重定向到https时,Curl会丢失正文

Question

当POST从http重定向到https时,Curl会丢失正文

我正在尝试使用curl 7.23.1将一些数据发送到我的服务器(运行nginx服务器).当nginx使用http://它查询时,它会重定向到https://它是否可以(如果它有密钥和所有mambo-jumbo)

看起来curl正在做点什么......很奇怪.出于兼容性原因,我的脚本(运行的东西curl)正在向其发送请求http://,但是当它遇到https://可用的服务器(因此被重定向)时,POST请求中的主体就会消失.

我正在尝试使用--data-urlencode name @ filename选项上传一堆文本.基本上,我运行一个脚本,将其输出转储到文件中/tmp/checkin/cmd_result,我想将其作为请求的"data"属性上传:

curl --max-time 30 --silent --location-trusted \
     --insecure --write-out "%{http_code}" --request POST \
     --data-urlencode "data@/tmp/checkin/cmd_result" \
     "http:/myserver/command_reply?command_id=524729ce93bc63292c1c9831" \
     --trace-ascii /tmp/command_response_trace.log \
     --output /tmp/checkin/cmd_res_resp --connect-timeout 10

Run Code Online (Sandbox Code Playgroud)

但重定向似乎剥夺了身体.如果我直接发送数据https://,一切都像魅力一样.添加-L(--location)或--location-trustedcurl指令似乎无法解决问题.

有人经历过同样的问题吗？任何帮助将深表感谢.

PS:

这是跟踪curl输出(我已经清理了一下):

=> Send header, 300 bytes (0x12c)
0000: POST /command_reply?&command_id=52
0040: 4729ce93bc63292c1c9831 HTTP/1.1
0061: User-Agent: curl/7.23.1 (mips-openwrt-linux-gnu) libcurl/7.23.1 
00a1: OpenSSL/1.0.1c zlib/1.2.7
00e4: Content-Length: 356
00f9: Content-Type: application/x-www-form-urlencoded
012a: 
=> Send data, 356 bytes (0x164)
0000: data=PING%20google.coms%0A
<= Recv header, 32 bytes (0x20)
0000: HTTP/1.1 302 Moved Temporarily
<= Recv header, 22 bytes (0x16)
0000: Server: nginx/1.1.19
<= Recv header, 37 bytes (0x25)
0000: Date: Sat, 28 Sep 2013 19:11:27 GMT
<= Recv header, 25 bytes (0x19)
0000: Content-Type: text/html
<= Recv header, 21 bytes (0x15)
0000: Content-Length: 161
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 120 bytes (0x78)
0000: Location: https://myserver/sensor/command_reply?command_id
0040: =524729ce93bc63292c1c9831
<= Recv header, 2 bytes (0x2)
0000: 
<= Recv data, 161 bytes (0xa1)
0000: <html>
0008: <head><title>302 Found</title></head>
002f: <body bgcolor="white">
0047: <center><h1>302 Found</h1></center>
006c: <hr><center>nginx/1.1.19</center>
008f: </body>
0098: </html>
== Info: SSLv3, TLS handshake, Client hello (1):
=> Send SSL data, 189 bytes (0xbd)
0000: .....
== Info: SSLv3, TLS handshake, Server hello (2):
<= Recv SSL data, 90 bytes (0x5a)
0000: .....
== Info: SSLv3, TLS handshake, CERT (11):
<= Recv SSL data, 3227 bytes (0xc9b)
0000: .....?.
== Info: SSLv3, TLS handshake, Server key exchange (12):
<= Recv SSL data, 525 bytes (0x20d)
0000: .^~...
== Info: SSLv3, TLS handshake, Server finished (14):
<= Recv SSL data, 4 bytes (0x4)
0000: ....
== Info: SSLv3, TLS handshake, Client key exchange (16):
=> Send SSL data, 134 bytes (0x86)
0000: ...'
== Info: SSLv3, TLS change cipher, Client hello (1):
=> Send SSL data, 1 bytes (0x1)
0000: .
== Info: SSLv3, TLS handshake, Finished (20):
=> Send SSL data, 16 bytes (0x10)
0000: ....
== Info: SSLv3, TLS change cipher, Client hello (1):
<= Recv SSL data, 1 bytes (0x1)
0000: .
== Info: SSLv3, TLS handshake, Finished (20):
<= Recv SSL data, 16 bytes (0x10)
0000: ...
=> Send header, 230 bytes (0xe6)
0000: POST /sensor/command_reply?command_id=52
0040: 4729ce93bc63292c1c9831 HTTP/1.1
0061: User-Agent: curl/7.23.1 (mips-openwrt-linux-gnu) libcurl/7.23.1 
00a1: OpenSSL/1.0.1c zlib/1.2.7
00bc: Host: myserver
00d7: Accept: */*
00e4: 
<= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
<= Recv header, 22 bytes (0x16)
0000: Server: nginx/1.1.19
<= Recv header, 37 bytes (0x25)
0000: Date: Sat, 28 Sep 2013 19:11:27 GMT
<= Recv header, 47 bytes (0x2f)
0000: Content-Type: application/json; charset=UTF-8
<= Recv header, 20 bytes (0x14)
0000: Content-Length: 22
<= Recv header, 24 bytes (0x18)
0000: Connection: keep-alive
<= Recv header, 2 bytes (0x2)
0000: 
<= Recv data, 22 bytes (0x16)
0000: {"r": 200, "data": {}}
== Info: SSLv3, TLS alert, Client hello (1):
=> Send SSL data, 2 bytes (0x2)
0000: ..

Run Code Online (Sandbox Code Playgroud)

Answer 1

Chu*_* Ma 10

看起来你的nginx进行了302重定向从http到https.根据RFC2616标准,您应该在nginx配置中使用301或307重定向.请从以下链接中查看更多信息.

请注意,一些用户代理(chrome,firefox,IE)进一步将302重定向视为GET请求,即使原始请求可能是POST.

参考:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

注意:RFC 1945和RFC 2068指定不允许客户端更改重定向请求的方法.但是,大多数现有的用户代理实现将302视为303响应,对Location字段值执行GET,而不管原始请求方法如何.已经为希望明确清楚客户端期望哪种反应的服务器添加了状态代码303和307.

更新

301也许不行.在curl手册中找到它.看起来curl也违反了RFC2616.所以你可能想先试试307.

当curl遵循重定向并且请求不是普通的GET(例如POST或PUT)时,如果HTTP响应是301,302或303,它将使用GET执行以下请求.如果响应代码是任何其他3xx代码,curl将使用相同的未修改方法重新发送以下请求.

归档时间：	12 年，5 月前
查看次数：	3846 次
最近记录：	12 年，5 月前