* Don't set 'content-length' with 'transfer-encoding'
When updating the response content for a response, avoid adding the
'content-length' header if the response contains a 'transfer-encoding'
header, from the spec [1]:
> When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body
Note the 'transfer-encoding' header is not used with HTTP/2
https://httpwg.org/specs/rfc7230.html#header.content-length
* don't crash when sending content-length+transfer-encoding
Co-authored-by: Maximilian Hils <git@maximilianhils.com>
When updating the response content for a response, avoid adding the
'content-length' header if the response contains a 'transfer-encoding'
header, from the spec [1]:
> When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body
Note the 'transfer-encoding' header is not used with HTTP/2
https://httpwg.org/specs/rfc7230.html#header.content-length
* mitmweb: handle {en,de}coding on server-side
Handle this server-side rather than passing the message content encoding
details back when fetching flow content. If {en,de}coding fails, return
the raw request contents.
This addresses https://github.com/mitmproxy/mitmproxy/issues/4809
* fix typo
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
I noticed when running tests the output of
`web/src/js/__tests__/ducks/_tflow.ts` would change depending on how I
set my timezone, e.g.
$ TZ=America/Los_Angeles pytest --quiet \
test/mitmproxy/tools/web/test_app.py >/dev/null \
&& grep --extended-regexp 'not(after|before)' web/src/js/__tests__/ducks/_tflow.ts
"notafter": 2235132207,
"notbefore": 1604415807,
$ TZ=Asia/Tokyo pytest --quiet \
test/mitmproxy/tools/web/test_app.py >/dev/null \
&& grep --extended-regexp 'not(after|before)' web/src/js/__tests__/ducks/_tflow.ts
"notafter": 2235074607,
"notbefore": 1604354607
It looks like this is because the `cert_to_json` function simply calls
`timestamp` the `datetime` object from
`x509.Certificate.not_valid_before`, however, this `datetime` object is
not timestamp aware, from the docs [1]:
> A naïve datetime representing the beginning of the validity period for
the certificate in UTC
So when serializing to JSON, first convert the `datetime` to UTC then
call `timestamp`.
A test was added by inspecting one of the test certs with:
$ openssl x509 -in test/mitmproxy/net/data/text_cert_2 -text
Extracting the date and asserting on that.
The corresponding test has also been re-run so that `_tflow.ts` was
regenerated with it's correct value. Snapshots were also updated via:
$(npm bin)/jest --updateSnapshot
[1] https://cryptography.io/en/latest/x509/reference/#cryptography.x509.Certificate.not_valid_after
Escape backslashes in pydocs containing '\*' (markdown escape sequence).
This removes the one warning I saw when running `pytest`:
/mitmproxy/mitmproxy/http.py:97: DeprecationWarning: invalid escape sequence \*
