英文:
mitmproxy: follow 3xx redirect without letting the client know?
问题
处理插件中的3XX
响应的惯用方法是什么,而不让客户端知道?
假设客户端发出对example.com
的请求。我们将请求传递给服务器并收到301
,Location: https://www.example.com
。我们不希望客户端看到这个,所以我们在客户端等待时向这个新位置发出新的请求。只有当我们收到200
响应时,我们才希望将响应发送回客户端。
首先想到的是responseheaders(flow)
挂钩。然而,似乎没有办法排队一个新的流,以便在当前流完成后运行,而不重置客户端连接。
request
挂钩有可能构造一个flow.response
,而处理程序永远不会向服务器发送任何内容。但是响应挂钩没有类似的选项。
即使我们中断当前的流程并使用ClientPlayback
发送新请求,我们仍然必须最终返回到当前的流程,因为它不知道关于ClientPlayback
的任何信息。如果我们终止它,不管是否中断,客户端的连接都将被关闭。
一些类似问题的建议都集中在在发送请求之前在request
挂钩中修改客户端请求;但如果我们无法预测301
将把我们发送到哪里,甚至在到达内容之前是否会有多次重定向呢?
想知道如何处理这种情况。
英文:
What's the idiomatic way to handle 3XX
responses in an addon without letting the client know?
Say a client issues a request to example.com
. We pass the request to the server and receive a 301
, Location: https://www.example.com
. We don't want the client to see this, so we issue a new request to this new location while the client is waiting. Only when we receive a 200
response do we want to send the response back to the client.
The first thing that comes to mind is the responseheaders(flow)
hook. However, there doesn't seem to be a way to queue a new flow to be run after the present flow completes without resetting the client connection.
The request
hook has the possibility to construct a flow.response
and the handler will never send anything to the server. But none of the response hooks have a similar option.
Even if we interrupt the current flow and use the ClientPlayback
to send a new request, we still have to eventually return to the current flow as it doesn't know anything about the ClientPlayback
. If we kill it, interrupted or not, the connection to the client will be closed.
A few suggestions to similar questions all focus on modifying the client request in the request
hook before it is sent; but what if we can't predict where the 301
will send us, or even if there will be several redirects before we get to content?
Curious how to handle this scenario?
答案1
得分: 0
一般来说,这是 mitmproxy 目前没有很好的答案的事情。一种可能的方法是在 async def request
钩子中使用类似 httpx 的库来填充 flow.response
,但这需要相当多的手动设置。
英文:
Generally speaking this is something mitmproxy does not have a great answer to at the moment.
One approach that comes to mind is to use a library like httpx in an async def request
hook to populate flow.response
, but that's quite a bit of manual setup.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论