six2dez
commented
4 months ago Most of the APIs used in this script are handled by Amass and/or Subfinder. There is a current rate limit for nuclei and other tools, but implementing a rate limit for APIs is not something I see as useful for this tool
Is your feature request related to a problem? Please describe. Yes, the problem arises when interacting with APIs that enforce rate limits, leading to potential disruptions and blocks if those limits are exceeded. I'm always frustrated when the script I use sends too many requests in a short period, risking exceeding the API's rate limits and negatively impacting my work, especially when dealing with sensitive endpoints.
Describe the solution you'd like I propose introducing rate limiting functionality within the script, allowing users to define the maximum number of requests sent per second. This feature is vital for ensuring the script operates within the API's rate limits, enhancing compatibility with a broader range of web services and making the tool more versatile and user-friendly.
Describe alternatives you've considered While the main proposal involves adding a
--rate-limitargument for straightforward rate control, an alternative could be to integrate more complex rate-limiting algorithms or to allow users to specify different rates for different endpoints. However, the simplicity and ease of use of a single rate-limit parameter might be preferable for most users.Additional context Implementing this feature would significantly improve the script's reliability and user experience, particularly for those interacting with APIs that have stringent rate limits. By enabling custom request pacing, we can prevent the script from causing unintended disruptions or service denials, ensuring smoother, more efficient operations.