-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HAR server replay missing content length in HEAD response #6547
Comments
cc @stanleygvi — no pressure I just saw that you contributed this feature recently <3 |
The following patch resolves this issue for me diff --git a/mitmproxy/http.py b/mitmproxy/http.py
index 986e6b898..d53f345b8 100644
--- a/mitmproxy/http.py
+++ b/mitmproxy/http.py
@@ -378,7 +378,7 @@ class Message(serializable.Serializable):
# don't set content-length if a transfer-encoding is provided
pass
else:
- self.headers["content-length"] = str(len(self.raw_content))
+ self.headers.setdefault("content-length", str(len(self.raw_content)))
def get_content(self, strict: bool = True) -> bytes | None:
""" This behavior looks like it was intentionally added in #4827 but I'm confused by it's different with HAR vs the binary storage. |
Thanks for the detailed report! I think we should keep flow.request.content = flow.request.content.replace(b"a", b"bb") to work in user addons. Many years ago we had it so that Instead, we should fix HAR loading to not use Contributions welcome! |
Thanks for the pointers! I was thinking about this later and came to similar conclusions that we should not change the behavior of |
#### Description Closes #6547 Responses in flows constructed from HAR files were using the `Response.make` utility which resulted in the injection of `content-length` headers. When a `content-length` header existed already, this could cause failures during replay. #### Checklist - [x] I have updated tests where applicable. - [x] I have added an entry to the CHANGELOG. --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Problem Description
When I use a HAR file for server response replay, my application fails with an error about missing content in the expected zip file response. It appears that the HEAD request's response does not properly include the
content-length
so the subsequent GET request is not made by the client? Perhaps there is another issue with chunked responses happening here.With hardump:
When I don't use HAR, you can see it sets the content length and there are subsequent requests:
The content length appears to be correctly encoded in the HAR file (expand)
Reproduction
I can work on a reproduction in the mitmproxy test suite as well as producing an example extracted from my application.
Roughly:
System Information
The text was updated successfully, but these errors were encountered: