Nice idea. Though, as expected, I'll need to make some changes :)

Will merge it during the weekend and do some updates afterwards

Let me know if there are some of those changes I can help with.

With latest revision, by uploading the --har output file to (e.g.) http://www.softwareishard.com/har/viewer/, user can get a nice presentation of requests/responses:

Nice addition of the timings and body size. Looks much better in the viewer. I was kind of expecting to make some of those final additions later on. Things like parsing back the cookies, request parameters and such.

Thank you for merging the changes. However, the follow-up changes kind of broke the functionality I was expecting from it. Namely, the HAR no so longer split into chunks and available from the API /data call.

If you are good with the plan, I would submit an additional PR to add back the API support while preserving the full-file generation.

Also, I had some unit tests in there which I just threw in the code file having no standard location to put them in. Would you like me to create a tests/ directory and add those to the CI build?

@lphuberdeau please, without unittests - because of "my highly subjective opinion", I don't like them inside the code.

As of broken functionality, can you please elaborate here what got broken? I am against the internal storage of HAR (e.g. into injection data) as it should be used strictly as (e.g.) -t <- for debugging purposes. As of providing its content via API, user can always run sqlmap with -v 5 to get loads and loads of traffic. I am kind of sceptic that anyone will require access to HAR via API.

p.s. cookies, queries ... are left empty the same way as (e.g.) Firefox leaves them empty. They are not so important in the first place.

I just find that the unittests speed-up my development cycle as testing the code takes less time than a full run. If you really don't want them, I'll strip them out when we get to "feature complete".

We use the HAR not only for debugging purposes, but also to show the user which behaviors helped identify the issue. Being able to reduce the HAR to a subset makes it more digestable. We get them through the API because that's just the way we archive the data.

Alternatively, I could mark the request/response pairs in the HAR and make sure these can be traced back from the API. The payloads would be smaller.

Regarding the additional properties, I understand they are not strictly required. However, they are convenient to add. It's a low priority element.