个人中心
gpt4 book ai didi

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

转载 作者：行者123 更新时间：2023-12-04 17:22:27 26 4
gpt4 key购买 nike

我正在尝试使用 curl 7.23.1 将一些数据发布到我的服务器(运行 nginx 服务器)。当这个nginx使用 http:// 查询，它重定向到 https://如果可以(如果它有 key 和所有的曼波巨无霸)

看起来 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

但重定向似乎剥离了 body 。如果我将数据直接发送到 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: ..

最佳答案

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

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

引用:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.



更新

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

When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.

关于post - 当 POST 从 http 重定向到 https 时，Curl 丢失正文，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19070801/

26 4 0
文章推荐： regex - Perl 单行匹配所有出现的正则表达式
文章推荐： prettier - 预提交钩子(Hook)(哈士奇 + 非常快)不起作用
文章推荐： javascript - 如何在 Gatsby 中将环境变量传递给 Sass 插件？
文章推荐： scala - 如何处理scala中 future 发生的异常
行者123
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com