* Partial gRPC contentview prototype, not linted, no tests, not as add-on
* Linted (flake8)
* Save dev state
* Rewrote of protobuf parser, use decoding strategy, reduced rendered data. Parser uses generators
* minor cleanup
* fix: preferred encoding was provided as function instead of value
* flake8: line length
* Backlinked message tree objects, temporary debug out
* Partial implementation of gRPC definitions. Save state to fix a cras (data invalidate in edit mode)
* hack: deal with missing exception handling for generator based content views
* gRPC/Protoparser descriptions (with test code)
* replaced manual gzip decoding with mitmproxy.net.encoding.decode
* Refactored typing imports
* Reafctoring
* distinguish request vs response definitions, separate view config from parser config
* Code cleaning, moved customized protobuf definitions to example addon
* final cleanup
* changelog
* Stubs for tests
* Fixed render_riority of addon example
* Started adding tests
* Work on tests
* mypy
* Added pseudo encoder to tests, to cover special decodings
* Example addon test added
* finalized tests, no 100 percent coverage possible, see comments un uncovered code
* minor adjustments
* fixup tests
* Typos
Co-authored-by: Maximilian Hils <git@maximilianhils.com>
* clarify that `IS_WINDOWS` includes WSL
* windows: fix file editing
tornado's asnycio patch does not take nonexisting file descriptors very well,
so we need to catch errors here.
* body editing: better editor guessing, fix#4798
* 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 \*
