HTTPClassyProbe has no limit on execution time or amount of data received, causing MID Server outage due to out of disk space on the system driveDescriptionDiscovery's HTTP Classification probe (HTTPClassyProbe) has no limit on execution or a limit on the amount of data received. For very large responses, this can result in disk space exhaustion up as the HTTPClient will buffer responses larger than 5MB to a temporary file on disk. As the large response from the classifier then cannot be handled, that large file is left in the temp folder.Steps to Reproduce Run a discovery where HTTPClassyProbe executes against a target and returns a very large response (100s of MB of data)On the MID host machine, notice that there will be "HTTPResponse<UUID>tmp" files in the operating system temp file directory with sizes in the 100s of MB Actual behaviour: File sizes of over 25GB (GigaBytes!) have been seen. On VMs that have e.g. 50GB total disk space for the OS, this can cause an outage for the host, and all mid servers on that host, and all higher level servicenow features and integrations working through them.e.g.01/18/2025 10:16 AM 2,066,598,945 HTTPResponse06376213910312101a278cf336804420tmp01/17/2025 03:48 PM 17,102,717,221 HTTPResponsef31d5113910312101a278cf336804420tmp01/18/2025 10:16 AM 2,066,598,945 HTTPResponse06376213910312101a278cf336804420tmp2024-09-09 02:43 PM 20�618�978�836 HTTPResponsef3753220bd2012108f4d46a0d15209aetmp03/07/2025 07:12 AM 25,351,771,306 HTTPResponse0ca22003740022100a819758d7255aa8tmp Expected behaviour: Now that PRB1648600 is fixed since Vancouver, which allows a max response size to be set on the HTTPRequest API in HTTPClassyConnectionFactory, the HTTPClassyProbe should now be using that to limit the response sizes, and not leave huge temp files on the disk.Temp files should always be cleaned up automatically after a probe completes, or is killed.WorkaroundThis problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available. It may be necessary to exclude an IP from Discovery Schedules, or disable a specific HTTP Classification, or HTTP Classification altogether, to avoid this problem. If the MID Server remains Up, you could use a 'Command' probe to confirm what is in the temp folder, and delete them for temporary relief. To see what's in the temp folder. This example is for Windows, but the equivalent Linux commands could also be used. Open a ECC Queue form: /ecc_queue.doFill in the form as: Agent: mid.server.*Topic: CommandName: dir %temp%\HTTPResponse*tmpQueue: OutputState: ReadyPayload: <parameters><parameter name="skip_sensor" value="true"></parameters> SaveCheck the ECC Queue for the inputs from all the MID Servers, which will have a payload listing the files. To delete the files. As above, but with: Name: del %temp%\HTTPResponse*tmpRelated Problem: PRB1592634