CloudMersove is supposed to return 200 for all scan calls, and the response body will indicate if the media contains viruses or not.
Unfortunately, we see instances where CloudMersive returns a 400, which means it is OUR error, since we are the one who make the call (it's not a client error). Our app correctly returns 500 when this happens because the 400 responses are not expected.
Unfortunately, our logging for CloudMersive errors only contains the http status message like so:
Error when calling Cloudmersive Virus Scan API: Bad Request
Which is not enough information for us to troubleshoot what about the request is wrong (e.g. a rate limit error? a body error? etc.)
Improve cloudmersive logs so we can (hopefully) understand the error better, and we can also have some data about the typical viruses (if any) that CM finds for us.
Documentation is unfortunately sparse (see here), but we can see that we should have access to the response object, which should allow us see everything we need about the response (e.g. headers, body).
This PR only includes non functional changes: it's just extra logging.
Tests
[ ] Add a new media file into a site. Find the enhanced log entry showing the detailed scan result in the meta block.
Problem
CloudMersove is supposed to return 200 for all scan calls, and the response body will indicate if the media contains viruses or not.
Unfortunately, we see instances where CloudMersive returns a 400, which means it is OUR error, since we are the one who make the call (it's not a client error). Our app correctly returns 500 when this happens because the 400 responses are not expected.
Unfortunately, our logging for CloudMersive errors only contains the http status message like so:
Which is not enough information for us to troubleshoot what about the request is wrong (e.g. a rate limit error? a body error? etc.)
Sample trace here
Solution
Improve cloudmersive logs so we can (hopefully) understand the error better, and we can also have some data about the typical viruses (if any) that CM finds for us.
Documentation is unfortunately sparse (see here), but we can see that we should have access to the
responseobject, which should allow us see everything we need about the response (e.g. headers, body).This PR only includes non functional changes: it's just extra logging.
Tests