This commit is largely based on work by Thiago Arrais (@thiagoarrais)
and Shane Bradfield (@l33tLumberjack). I wasn't really able to get their
PR reasonably merged onto the latest master, so I reapplied their changes
manually here and did some further improvements on that.
In transparent mode host is set with the target server ip.
Attribute flow.request.host is used as SNI while mitmproxy is
initiating TLS handshake, so it should be set with the pretty_host.
While the HAR spec is not very explicit and their example shows just this one example: ```json
"postData": {
"mimeType": "multipart/form-data"
}
```
Would it not make sense to include all the information necessary to parse out the post data `text`. Eg.
```json
"postData": {
"text": "--xYzZY\r\nContent-Disposition: form-data; name=\"sort1\"\r\n\r\noldest date first\r\n--xYzZY--\r\n",
"mimeType": "multipart/form-data; boundary=xYzZY"
},
```
Currently, full mimeType is included only in `content-type` request header.
Elsewhere in HAR spec they include the 'extras', eg ```json
"content": {
"mimeType": "text/html; charset=utf-8"
}
```
So one could argue that `mimeType` should include all information necessary to interpret the data. In case of `multipart/form-data`, as per RFC2046 http://www.ietf.org/rfc/rfc2046.txt
```
The Content-Type field for multipart entities requires one parameter, "boundary".
```
I believe that earlier incarnations, eg `har_exporter.py` included it in the mimeType.
The primary motivation here (and for all the other moving around) is to present
a clean "front of house" to library users, and to migrate primary objects to
the top of the module hierarchy.
- Don't log a traceback for either HTTP or HTTPS DNS resolution or TCP
connection errors. These are "ordinary" errors, not mitmproxy issues.
- Ensure that the error handler is correctly called for SSL-related protocol
errors.
