5

我正在尝试使用 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-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: ..
4

1 回答 1

10

看起来您的 nginx 执行了从 http 到 https 的 302 重定向。根据 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 将使用相同的未修改方法重新发送以下请求。

于 2013-09-29T04:46:52.877 回答