通过HTTPS使用python请求似乎会损坏有效负载 我在校园项目中用C++构建了一个Web服务器。我决定使用Python3和request为restfulapi构建自动化测试。但是，我遇到了一个问题，当通过HTTPS发送请求时，服务器无法正确解码我的请求正文

以下是通过http的预期响应和请求：

>>> resp = requests.post("http://127.0.0.1:8080/usager/identification", verify=False, json={"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "test_user1"}) ; resp.content
b'{"identificateur":4139190850,"message":"connection successful"}'

但是通过https，我收到了一个“格式错误的请求”，这意味着服务器没有在有效负载中找到

ip

、

mac

和

nom

：

>>> resp = requests.post("https://127.0.0.1:4433/usager/identification", verify=False, json={"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "test_user1"}) ; resp.content
/usr/lib/python3.7/site-packages/urllib3/connectionpool.py:847: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
b'Malformed request'

奇怪的是，它通过HTTPS与curl一起工作：

curl -k -X POST https://127.0.0.1:4433/usager/identification --data '{"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "test_user1"}' && echo {"identificateur":4139190850,"message":"connection successful"}

我还尝试在python中使用

data

而不是

json

，结果类似：

>>> resp = requests.post("https://127.0.0.1:4433/usager/identification", verify=False, data='{"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "test_user1"}') ; resp.content
/usr/lib/python3.7/site-packages/urllib3/connectionpool.py:847: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
b'Malformed request'

我搞不清什么请求与这里的curl不同。我总是可以在python代码中为这个测试硬编码一个curl命令，但这毫无意义

谢谢你抽出时间

编辑： 具有详细输出的curl：

{16:34}~/code/tp/inf3995-01/project/server/src/common/test:f341 ✗ ➭ curl -v -k -X POST https://127.0.0.1:4433/usager/identification --data '{"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "test_user1"}' && echo
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 4433 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=CA; ST=Quebec; O=Caf�-Bistro �l�vation, Inc.; CN=127.0.0.1
*  start date: Nov  8 18:38:05 2018 GMT
*  expire date: Nov  8 18:38:05 2019 GMT
*  issuer: C=CA; ST=Quebec; L=Montreal; O=Team One, Inc.; OU=Server Dept.
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> POST /usager/identification HTTP/1.1
> Host: 127.0.0.1:4433
> User-Agent: curl/7.62.0
> Accept: */*
> Content-Length: 66
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 66 out of 66 bytes
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/1.1 200 OK
< Connection: Keep-Alive
< Content-Length: 63
< 
* Connection #0 to host 127.0.0.1 left intact
{"identificateur":4139190850,"message":"connection successful"}

服务器端的数据：

(gdb) p body
$29 = "{\"ip\": \"12.2.2.2\", \"mac\":\"FF:11:11:DD:DD:DD\", \"nom\": \"test_user1\"}"

(gdb) p body
$31 = "\000{\"ip\": \"12.2.2.2\", \"mac\":\"FF:11:11:DD:DD:DD\", \"nom\": \"tesr1\""

并应要求：

请求：

>>> headers = {'Connection': 'Keep-Alive', 'Content-Type': 'application/x-www-form-urlencoded'}
>>> data = '{"ip": "12.2.2.2", "mac":"FF:11:11:DD:DD:DD", "nom": "tesr1"}'
>>> response = requests.post("https://127.0.0.1:4433/usager/identification", verify=False, headers=headers, data=data) ; response.text

服务器端的主体：

(gdb) p body
$29 = "{\"ip\": \"12.2.2.2\", \"mac\":\"FF:11:11:DD:DD:DD\", \"nom\": \"test_user1\"}"

(gdb) p body
$31 = "\000{\"ip\": \"12.2.2.2\", \"mac\":\"FF:11:11:DD:DD:DD\", \"nom\": \"tesr1\""

---

因此，在请求中使用相同的数据会导致数据损坏：在开始处添加空终止符，并删除右括号。

能否提供

curl

详细输出？这可能有助于识别问题。curl发现了我不久前设置的过期证书，我不确定它是否相关。您是否尝试在Python中指定证书，因为他们的请求在加密之前应该是相同的。您是否也可以为请求打开详细日志记录？阅读全文，转到链接并遵循guid。