Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Add raw request/response data to reports #349

user021 opened this Issue · 8 comments

4 participants


Hi, could you add more info on headers, like full request including the affected variable


other web scanner:

@Zapotek Zapotek was assigned

+1, The way the web front end renders the response is nice, although as mentioned above, full request and response (both with headers) would be awesome. allows you to push the raw request straight into other tools. ie. sqlmap -r request


Yeah that was my thinking too. I've already opened a ticket on the HTTP client used by Arachni: typhoeus/ethon#63
Once that's sorted I'll implement this in Arachni.


Seems like this could be supported by: typhoeus/typhoeus#247

However, I've got to make sure to check how this affects performance -- debug/verbose options may carry a penalty.


+1 fr0m me..:)

but, not sure about the extra amout of data going over the wire..

anyway, 4me, ara only sends like ~500 req, then im done, and have my bug..:)


Erm, which wire? There won't be any more data sent over HTTP. You mean extra report data?


So just an idea, given you have recently updated/defined the levels of verbosity, when a finding is discovered, would you consider dumping the entire request (headers and body) to the screen when verbosity is max? this would allow you to take the request and manually verify without having to wait for the scan to complete?

I guess the end goal that I would find useful would be to have access to the full request (and less importantly the response) prior to completion of the scan from either WebUI or CLI.


I've only added levels to the debug function, verbosity is still on or off. While your case would certainly benefit from verbosity levels, wouldn't it be better served from the run-time report generation feature?

That way you'll immediately get all available data to verify the issues and in a much more usable format.
I guess it comes down to having the foresight of specifying a report format against having the foresight of specifying a verbosity level.

I'll might as well add support for multiple verbosity levels since I'm at it though, so you'll get the behavior you suggested.




@Zapotek Zapotek closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.