Question

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

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

我正在尝试使用--data-urlencode name@filename选项上传一堆文字。基本上，我运行一个脚本，将其输出转储到文件/tmp/checkin/cmd_result中，我想将其作为请求的“数据”属性上传：

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

但重定向似乎剥离了身体。如果我将数据直接发送到https://，一切都像魅力一样。将-L（--location）或--location-trusted添加到curl指令似乎无法解决问题。

有人遇到过同样的问题吗？任何帮助都将深表感谢。

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: ..

Answer 1

看起来你的nginx会从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 响应，无论如何都对位置字段值执行GET 原始请求方法。状态代码303和307具有已添加到希望明确清楚哪些服务器的服务器对客户的反应是预期的。

<强>更新

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

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

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

1 个答案: