Small consistency issues: error shapes, booleans, a few messages, date formats, and silently dropped IDs #180

Each of these is small, so I've grouped them into one issue rather than filing seven.

1. The same field can return errors in two different shapes. Errors from the router (express-validator) come back as an array (routes/index.js#L58-L66), while errors from the middleware come back as a single object:

   • {"resultsPerPage":0} gives {"error":"RESULTS_PER_PAGE_INT",...}
   • {"resultsPerPage":501} gives [{"error":"MAX_RESULTS_LIMIT",...}]

   It would be easier for clients if it were always {"errors":[...]}, or always a single object.

2. One message points at the wrong problem. resultsPerPage: "abc" or 1.5 returns MAX_RESULTS_LIMIT ("must be ... less than or equal to 500"). The actual problem is that it needs to be an integer from 1 to 500.

3. Booleans aren't handled the same way everywhere. isVulnerable, keywordExactMatch, and noRejected accept the strings "true" and "false", but knownExploited and disputed reject them. I tested knownExploited, which returns KNOWN_EXPLOITED_BOOLEAN; for disputed I'm going by the code (routes/index.js#L382-L398). Either rule is fine; it would just be good to pick one.

4. The date format is very strict. Only yyyy-MM-ddTHH:mm:ss.SSSZ is accepted. 2024-01-01, 2024-01-01T00:00:00Z, and +00:00 offsets all return 400. Accepting RFC 3339/ISO 8601 would help, including a plain date, with start dates meaning UTC midnight and end dates covering the whole day. Separately, the error message shows the pattern as yyyy-MM-ddTHH:mm:ss.SSS'Z', which looks garbled.

5. IDs that don't exist are dropped without a warning. cveIds: "CVE-2024-5981,CVE-2099-99999999" returns one record and no warning, but pre-1999 IDs do get a CVE_IDS_NOT_RETURNED warning. A CVE_IDS_NOT_FOUND warning listing the IDs that weren't returned would be handy, especially while some records are missing from the index (see the freshness issue).

6. Error messages echo back the input. Severity errors repeat what was sent, upper-cased: <B>X</B> is not an allowed input.... It's low risk in a JSON response, but listing the allowed values without echoing the input would be cleaner.

7. A few things about response headers:

   • There are no RateLimit-* headers, so clients can't slow down before hitting a 429.
   • There's an ETag but no Cache-Control, even though the Responsible Use Guide asks clients to cache.
   • The response includes x-powered-by: Express.
   • For what it's worth, the User-Agent the guide asks for doesn't seem to change anything. Real curl, a custom UA, no UA, Python, and browser UAs all got identical responses. That's fine; I just thought you'd want to know.