| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
If I had a thousand years and every thesaurus in the world, I still couldn't
adequately express how much I dislike this piece of interface design.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 HAR spec isn't really clear on whether this should be the case,
but Google Chrome does this, so I think we should too.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The HAR Spec says that the field can be left out by applications that don't
group by pages.
http://www.softwareishard.com/blog/har-12-spec/#log
|
| |
|
