Ideally, if the client requests STIX 2.0, the server responds with valid STIX 2.0 and the appropriate content type. If the client asks for STIX 2.1 (or optionally, the STIX content type without a version), then the server should (or could
if no version is specified) return 2.1 content.
Jason, I don’t think it’s a bug for the taxii client library to reject a response with STIX 2.1 content type when it asked for STIX 2.0. It would certainly be a valid feature request that the library allow you to configure what version
you are asking for, though. :-)
Greg
Maintaining separate branches would be the best for us on this end.
Principle Engineer – Data Science & Analytics
From: cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Sent: Wednesday, November 8, 2017 8:48:25 AM
To: Jason A. Evans
Cc: Bret Jordan; cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Re: [EXT] [cti-users] Client Python Code
I can change the server response to be just 2.0. I am building this solution in preparation for the OASIS TC’s future release of STIX 2.1 and as features get marked as done for 2.1 I have started including them (confidence, internationalization,
etc).
Sorry if this causes any confusion.
Bret
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
Yes, it's fixed. Thanks so much Bret!
Greg: Bug report incoming. The server response now indicates STIX 2.1 (application/vnd.oasis.stix+json; version=2.1).
On Wed, Nov 8, 2017 at 12:56 AM, Bret Jordan <jordan2175@gmail.com> wrote:
Jason,
This should be fixed now. Please let me know, and thanks for bringing that to my attention.
On Tue, Nov 7, 2017 at 12:59 PM, Jason A. Evans <jasonevans77@gmail.com> wrote:
I'm kind of at a loss. Rechecked everything. Really seems like the server is returning something different/incorrect compared to yesterday. Below is my simple Python code followed by the error.
=============================================
|