mitmproxy:跟随3xx重定向,而不让客户端知道?

huangapple go评论48阅读模式
英文:

mitmproxy: follow 3xx redirect without letting the client know?

问题

处理插件中的3XX响应的惯用方法是什么,而不让客户端知道?

假设客户端发出对example.com的请求。我们将请求传递给服务器并收到301Location: 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.

huangapple
  • 本文由 发表于 2023年3月3日 18:41:47
  • 转载请务必保留本文链接:https://go.coder-hub.com/75626031.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定