简体   繁体   English

Python 请求未编码正斜杠

[英]Python Requests Not Encoding Forward Slashes

I'm working on a tool that needs to make requests to a site using the application/x-www-form-urlencoded content type.我正在开发一个需要使用application/x-www-form-urlencoded内容类型向站点发出请求的工具。 When I make the request from ARC for Chrome , I get the expected response.当我从ARC 向 Chrome发出请求时,我得到了预期的响应。 When I reproduce the request using requests for Python 3, I get a different response that is not at all what I expected.当我使用 Python 3 的请求重现请求时,我得到了一个完全不是我预期的不同响应。

I opened WireShark to find differences between the request coming from ARC and the request coming from the Python script.我打开 WireShark 来查找来自 ARC 的请求与来自 Python 脚本的请求之间的差异。 The content of the URL-encoded form, from WireShark, for the ARC request is as follows:来自 WireShark 的 ARC 请求的 URL 编码表单的内容如下:

TransType=INQ&TransID=RESINQ&ReturnPage=%2Fdmvnet%2Fplate_purchase%2Fs2end.asp&HelpPage=&Choice=A&PltNo=TSPOON&HoldISA=N&HoldSavePltNo=&HoldCallHost=&NumCharsInt=8&CurrentTrans=plate_purchase_reserve&PltType=IGWT&PersonalMsg=Y&Let1=T&Let2=S&Let3=P&Let4=O&Let5=O&Let6=N&Let7=&Let8=

The content of the URL-encoded form, from WireShark, for the Python script request is as follows:来自 WireShark 的针对 Python 脚本请求的 URL 编码表单的内容如下:

TransType=INQ&TransID=RESINQ&ReturnPage=/dmvnet/plate_purchase/s2end.asp&HelpPage=&Choice=A&PltNo=TSPOON&HoldISA=N&HoldSavePltNo=&HoldCallHost=&NumCharsInt=8&CurrentTrans=plate_purchase_reserve&PltType=IGWT&PersonalMsg=Y&Let1=T&Let2=S&Let3=P&Let4=O&Let5=O&Let6=N&Let7=&Let8=

The only difference that I see (and that a diff checker reports) between these two is the ReturnPage .我看到的(以及差异检查器报告的)这两者之间的唯一区别是ReturnPage In the request from ARC, the forward slashes are translated to %2F , and in the request from the Python script they remain unencoded.在来自 ARC 的请求中,正斜杠被转换为%2F ,而在来自 Python 脚本的请求中,它们保持未编码。 Shouldn't the requests library be performing this encoding? requests库不应该执行这种编码吗? When I use a raw string in Python the %2F itself gets encoded ( ReturnPage=%252Fdmvnet%252Fplate_purchase%252Fs2end.asp ).当我在 Python 中使用原始字符串时, %2F本身会被编码( ReturnPage=%252Fdmvnet%252Fplate_purchase%252Fs2end.asp )。 Does the lack of encoding from the requests library even matter here? requests库中缺少编码在这里是否重要?

I am using the application/x-www-form-urlencoded header...我正在使用application/x-www-form-urlencoded header ...

headers = {
    "content-type": "application/x-www-form-urlencoded"
}

body = {
    ...
}

response = requests.post("myUrlHere", data=body, headers=headers)

The response that comes back from the Python script using requests is as follows:使用requests从 Python 脚本返回的响应如下:

Status Code: 200
Headers: {
    'Cache-Control': 'private',
    'Content-Type': 'text/html',
    'Server': '',
    'Set-Cookie': 'WebSessionDataID=20200816233709078125172161292511; path=/, ASPSESSIONIDQERAATBR=ODECNAOABGCGADAJEMCCNIDM; secure; path=/',
    'Date': 'Mon, 17 Aug 2020 03: 37: 08 GMT', 'Content-Length': '0'
},
Content: "" (Empty)

The anticipated response is a 302 Object Moved with a destination of the requested resource provided in the response headers.预期的响应是 302 Object 已移动,响应标头中提供的请求资源的目的地。

It has nothing to do with the encoding of forward slashes.它与正斜杠的编码无关。 According to the documentation :根据文档

By default Requests will perform location redirection for all verbs except HEAD.默认情况下,请求将对除 HEAD 之外的所有动词执行位置重定向。

This means that if a 302 (Found) is received (or, in general, any 3xx response status code), the request is automatically redirected to the received location.这意味着如果接收到 302(找到)(或者,通常是任何 3xx 响应状态代码),请求会自动重定向到接收到的位置。 If you do not want this, the same documentation says:如果你不想要这个,相同的文档说:

If you're using GET, OPTIONS, POST, PUT, PATCH or DELETE, you can disable redirection handling with the allow_redirects parameter:如果您使用 GET、OPTIONS、POST、PUT、PATCH 或 DELETE,您可以使用 allow_redirects 参数禁用重定向处理:

And provides this example:并提供了这个例子:

>>> r = requests.get('http://github.com/', allow_redirects=False)

>>> r.status_code
301

>>> r.history
[]

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM