aboutsummaryrefslogtreecommitdiffstats
path: root/examples/full_transparency_shim.c
diff options
context:
space:
mode:
authorSlobodan Mišković <slobodan@miskovic.ca>2016-10-24 14:34:04 -0700
committerGitHub <noreply@github.com>2016-10-24 14:34:04 -0700
commit39d7ba852c38e45322a55794fba9e06d7fcbc6ce (patch)
treeaac93c76aa448615c69274982c92e8373560528e /examples/full_transparency_shim.c
parentea2d6474bf1e9c4c1fd2e4a6ac33e0785fc751de (diff)
downloadmitmproxy-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