Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept more flexible content type strings #10

Closed
clenk opened this issue Oct 4, 2017 · 1 comment
Closed

Accept more flexible content type strings #10

clenk opened this issue Oct 4, 2017 · 1 comment
Assignees
Milestone

Comments

@clenk
Copy link
Contributor

clenk commented Oct 4, 2017

When checking the content type of packets the client receives, it checks if it is an exact match (https://github.com/oasis-open/cti-taxii-client/blob/master/taxii2client/__init__.py#L481). This fails if for example "; charset=utf-8" is appended to the content type.

clenk added a commit to clenk/cti-taxii-client that referenced this issue Oct 4, 2017
Accept Content-Type strings that aren't exact matches but start with the
same format. This allows for options like 'charset' to be used in the
Content-Type.

Fixes oasis-open#10.
@gtback gtback closed this as completed in #11 Oct 4, 2017
@gtback gtback added this to the 0.2 milestone Nov 7, 2017
@varnerac
Copy link

I thought that this should be relaxed too, at first. However, reading the JSON spec, charset=utf-16, etc. should not be allowed. RFC 8529 disallows them. RFC8529 is very recent, December 2017. It actually recommends UTF-8 only except for "closed systems."

TAXII-2.0 references RFC 7159 which was obsoleted by RFC 8529.

Section 3 of RFC 4627 demonstrates how to determine the character set of JSON without the charset parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants