json output fields to be adjusted

[percepo]

Some of the fields follow misleading naming conventions. "result_number" implies a chronological order of results, which wenum has long parted from "post_data" is usually correct in practice, but adding values to the request body may be restricted to POST requests by suggested standards, but wenum can do that with any kind of request "description" is misleading, as there is little to describe. Its misc info, or something else. Currently I believe often (no guarantee) used for the path. Should get refactored in total Additionally, having the port number be in a separate field would be nice, as that is often not explicit in the URL (especially if http or https). That would help post processing to make easier comparisons. "plugins" is not really correct. It is named in front and backend that way, but not only plugins provide such information. It moreof clashes with "description", meaning the field provides info that came while processing the item during the runtime. That includes plugins, but sometimes its optional queues, and sometimes its from the very core. "processing_info" should be a better term. Whatever was supposed to be in the description field can then be added there as another dict entry Also, deviating from the "char" syntax is another goal. That term is not reliable, as in the background it merely takes the byte size of the response, which often is not the same thing. Simply calling it "bytes" should be the best way.

Completely open: The html output will need a hierarchical output. It would be up for debate on whether the json should inherently contain this hierarchical format, but I think for the purposes of the json file, that is not beneficial and might even be a minus, as now processing the json for any purpose that doesnt need that structure becomes more convoluted

Changes should be done carefully and in one go. Changing the json output is a difficult topic, as tooling processing the output depends on the format.

[percepo]

67 will likely also bring the difficulty of logging information not specific to any individual request.

This will most likely make it necessary to have all fuzzresults beneath a similarly called jsonfield, and all non-fuzzresult specific infos in a separate attribute.

[percepo]

With the new UI and rendering of strings, output of plugins does not seem to be formatted properly anymore. It should be adjusted to strip all rich library rendering tags such as [u]output[/u]

[percepo]

Also, the entire output file is wrapped has been wrapped in an array. As by design there won't be multiple objects of the same root level of objects, the array form will be gotten rid of, as that also is valid JSON and avoids unnecessary nesting.