Skip to content

Content type octet-stream #116

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

Closed
pawamoy opened this issue Aug 3, 2020 · 3 comments · Fixed by #157
Closed

Content type octet-stream #116

pawamoy opened this issue Aug 3, 2020 · 3 comments · Fixed by #157
Labels
✨ enhancement New feature or improvement
Milestone

Comments

@pawamoy
Copy link

pawamoy commented Aug 3, 2020

Describe the bug
I'm getting this parsing error:

MULTIPLE ERRORS WHILE PARSING:
ERROR parsing GET /api/v1/datasetversion/{dataSetVersionID}/read_data within datasetversion. Endpoint will not be generated.
{'content': {'application/octet-stream': {'schema': {'format': 'stream',
                                                     'type': 'string'}}},
 'description': 'The method returns the stream of the file associated to the '
                'version of a dataset'}
Unsupported content_type {'application/octet-stream': {'schema': {'type': 'string', 'format': 'stream'}}}

To Reproduce
I'm not sure I can share the spec here, I will try to clean it up to give you a MRE.

Expected behavior
openapi-python-client supports the octet-stream content-type.

OpenAPI Spec File
Same remark as above: I'm not sure I can share the spec here, I will try to clean it up to give you a MRE.

Desktop (please complete the following information):

  • OS: RedHat 7
  • Python Version: 3.7.8
  • openapi-python-client version 0.4.2
@pawamoy pawamoy added the 🐞bug Something isn't working label Aug 3, 2020
@dbanty
Copy link
Collaborator

dbanty commented Aug 3, 2020

@pawamoy what sort of Python type would you expect from an octet-stream. bytearray maybe? or bytes? I think if we just enabled the content type right now it would attempt to decode the payload into a string with whatever the default encoding is (UTF-8 probably) which I assume would error.

@pawamoy
Copy link
Author

pawamoy commented Aug 3, 2020

Thanks for the quick reply @dbanty! Yeah I guess bytes makes most sense? We shouldn't try to decode it and rather leave that task to the client user.

Feel free to mark this a feature request instead of bug by the way :)

@dbanty
Copy link
Collaborator

dbanty commented Aug 13, 2020

@emannguitar looking at the example given here, they're using a custom (not part of OpenAPI standard) string format. I believe that would end up being a normal str(response.text) in Python given the implementation in your PR. No idea what that would do if the response was bytes.

Given that application/octet-stream is supposed to always contain "arbitrary binary data" (source) does it make sense to just always force the BytesResponse for that content type?

dbanty pushed a commit that referenced this issue Aug 13, 2020
* Added support for octet-stream content type (#116)

Co-authored-by: Ethan Mann <[email protected]>
@dbanty dbanty added ✨ enhancement New feature or improvement and removed 🐞bug Something isn't working labels Aug 13, 2020
@dbanty dbanty added this to the 0.5.4 milestone Aug 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants