-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Enable binary support for WSClient #2194
Enable binary support for WSClient #2194
Conversation
|
Welcome @meln5674! |
/assign @yliaog |
Currently, under python 3, the WSClient decodes all data via UTF-8. This will break, e.g. capturing the stdout of tar or gzip. This adds a new 'binary' kwarg to the WSClient class and websocket_call function. If this is set to true, then the decoding will not happen, and all channels will be interpreted as binary. This does raise a slight complication, as the OpenAPI-generated client will convert the output to a string, no matter what, which it ends up doing by (effectively) calling repr(). This requires a bit of magic to recover the orignial bytes, and is inefficient. However, this is only the case when using the default _preload_content=True, setting this to False and manually calling read_all or read_channel, this issue does not arise.
eadfcaa
to
488518d
Compare
thanks for the PR /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: meln5674, yliaog The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Currently, under python 3, the WSClient decodes all data via UTF-8. This will break, e.g. capturing the stdout of tar or gzip. This adds a new 'binary' kwarg to the WSClient class and websocket_call function. If this is set to true, then the decoding will not happen, and all channels will be interpreted as binary.
This does raise a slight complication, as the OpenAPI-generated client will convert the output to a string, no matter what, which it ends up doing by (effectively) calling repr(). This requires a bit of magic to recover the orignial bytes, and is inefficient. However, this is only the case when using the default _preload_content=True, when setting this to False and manually calling read_all or read_channel, this issue does not arise.
Which issue(s) this PR fixes:
Fixes #1471
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: