openVulnQuery Python client gives 406 instead of 404 for not found elements

[santosomar]

When querying for a given date range such as:

https://api.cisco.com/security/advisories/all/firstpublished?startDate=2018-10-11&endDate=2018-10-11

The client gives the following error:

requests.exceptions.HTTPError: 406 Client Error: Not Acceptable for url: https://api.cisco.com/security/advisories/all/firstpublished?startDate=2018-10-11&endDate=2018-10-11

It should be a 404 - not found, since there were no advisories published that day.

[Ch3ssNa]

You also get the same error if you query for a ios version that is not valid

URL = https://api.cisco.com/security/advisories/iosxe?version=16.6.not-_valid
HTTP Status Code: 406
Return Text: "errorCode":"INVALID_VERSION_FORMAT","errorMessage":"Invalid version ids format, Special charaters are not allowed (&,!,$,',@,#,!,<,?,(,)). Valid example's '12.1(8a)E3' ,'3.7.1aS' etc"

But also if a IOS version is not found with a valid format

URL = https://api.cisco.com/security/advisories/iosxe?version=16.6.DONTexist
HTTP Status Code: 406
Return Text: "errorCode":"INVALID_IOSXE_VERSION","errorMessage":"IOSXE version not found"

The same behavior can be replicated with querying by advisory-id. I would assume that this miss behavior is true for the complete API. From my perspective this is not a issue on the python client side. It looks more like an issue on the implementation of the API itself.

You also get a correct 406 response if you send wrong headers like this:

        self.header = {
            "Accept": "application/jsona",  <-- This is not valid and the Server can not return this application
            "Content-type": "application/json",
            "Authorization": "Bearer {}".format(outh_token),
        }

In this case the 406 response is correct.

URL = https://api.cisco.com/security/advisories/advisory/cisco-sa-20181128-plm-sql-inject
HTTP Status Code: 406
Header returned from server: 
'Date': 'Sun, 09 Dec 2018 12:35:11 GMT',
 'Server': 'Mashery Proxy', 
'X-Mashery-Message-ID': '205330cb-0f66-4cc0-a1ab-9bf45f50a52d',
'Cache-Control': 'private',
'Pragma': 'private',
'Content-Length': '0', 
'LAEHOST': 'lae-alln-mi-112.cisco.com',
'Access-Control-Allow-Credentials': 'true',
'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
'Access-Control-Allow-Headers':
    'Content-type,
    fromPartyID,
    inputFormat,
    outputFormat,
    Authorization,
    Content-Length,
    Accept, Origin',
'Content-Type': 'text/plain; charset=UTF-8',
'X-RP-SSL-Name': 'lae-rcdn-rpi-04',
'Connection': 'close'}

[santosomar]

Thank you @Ch3ssNa for the detailed explanation. The dev team is looking into this now. Hope to have a solution soon.

[santosomar]

Note: Prior to October 4th 2019; the HTTP error code returned was 406. The correct error code (error code 404) was introduced with a fix on October 4th, 2019.