diff options
author | Slobodan Mišković <slobodan@miskovic.ca> | 2016-10-24 14:34:04 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2016-10-24 14:34:04 -0700 |
commit | 39d7ba852c38e45322a55794fba9e06d7fcbc6ce (patch) | |
tree | aac93c76aa448615c69274982c92e8373560528e /examples/full_transparency_shim.c | |
parent | ea2d6474bf1e9c4c1fd2e4a6ac33e0785fc751de (diff) | |
download | mitmproxy-39d7ba852c38e45322a55794fba9e06d7fcbc6ce.tar.gz mitmproxy-39d7ba852c38e45322a55794fba9e06d7fcbc6ce.tar.bz2 mitmproxy-39d7ba852c38e45322a55794fba9e06d7fcbc6ce.zip |
Include `boudary=...` in mutipart postData
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.
Diffstat (limited to 'examples/full_transparency_shim.c')
0 files changed, 0 insertions, 0 deletions