A provisioning script that posts new device records to SD-WAN Manager now fails, and the log shows only 'HTTP 400 Bad Request'. The same script also returns 401 on long overnight runs. How should the script read each API error response to diagnose both failures?
Select an answer to reveal the explanation.
Short Explanation
You can diagnose the 400 by logging both the status code and response body, which may explain why the request was rejected. If a long run returns 401, renew your authentication and investigate your credentials if the problem continues.
Full Explanation
The correct approach logs both the HTTP status code and response body: the status identifies the class of failure, while the body may contain controller-specific details needed to diagnose a 400. A 401 during a long run warrants checking whether authentication has expired and renewing it, or investigating the credentials if renewal does not resolve the problem. Logging each status and body but retrying an overnight 401 with the same token preserves useful evidence, yet does not address the failure if the token has expired. Logging the status and reason phrase, then refreshing authentication or checking credentials, handles the 401 appropriately but discards the response body, which may explain why a request was rejected. Logging the 400 body and renewing authentication after a long-run 401 captures useful details for the 400, but omitting the 401 body leaves that response only partly recorded and may hide diagnostic information. Exam caveat: a 400 often points to a malformed or invalid request, but the status alone does not establish the precise cause; interpret it alongside the body. Practical check: confirm logs retain the status and body for both failure types, and verify the script can renew its token during a long run before retrying.