-
Notifications
You must be signed in to change notification settings - Fork 184
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Codecov Report
@@ Coverage Diff @@
## master #104 +/- ##
=======================================
Coverage 92.04% 92.04%
=======================================
Files 13 13
Lines 1182 1182
=======================================
Hits 1088 1088
Misses 94 94 Continue to review full report at Codecov.
|
can anyone approve this? |
/assign @roycaihw |
Btw, don't know if it is correct to discuss here - i know that 'replace' is kind of solution, but it seems to me that it is incorrect to decode chunks of data without preliminary concatenation. For me it looks like chunk can really be broken - if it's bytes it's not necessary complete information about encoded symbol, but it may be just the first byte of two bytes total. In that case adding 'replace' could just corrupt data received by client. |
i am agree with your. but in my scene: \����̋���܍��, if i use python-base , i get an exception when reading data. i want to do same things with |
I beleive kubectl throws raw binary data to output, but I'm not sure it tries to decode data partially. I assume correct solution to this wold be to merge chunks, then try to decode it with 'replace'. But I'm not sure, that's just guess, need to dig deeper -) |
from the rfc I think we should decode utf8 if opcode is the previous implementation seems to be modeled from WebSocketApp but I don't see why we assumed utf8 for |
ok. as I understand, we should mark whole channel by the first frame opcode to treat all it's parts the same way? opcode isn't supposed to change fron frame to frame, right? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
I checked the websocket-client module that we depend on. It looks like the module has handled fragment concatenation for us already our ws client invokes python-base/stream/ws_client.py Line 177 in 1d5231c
the websocket-client extracts the data type (text or binary) from the first frame, and accumulates following continuation frames into the payload. The client only returns the ws message when the last fragment (FIN) is received. Note that we've disabled I don't think we need one more layer to concatenate multiple ws messages. websocket-client guarantees each text-type ws message can be decoded as utf8. It's just we shouldn't assume binary-type ws messages can be decoded in the same way |
@roycaihw ok, that's great! Seems like there is no trouble with ws anymore.
So it looks like this concrete PR is outdated, but could you please take a look at #112 especially https://github.com/kubernetes-client/python-base/pull/112/files#diff-7768487132d1edef2f3cb4e8d4101890 ? |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: roycaihw, saberuster 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 |
as mentioned above #88 .
we can determine whether data is utf8 encode in another way,instead of raise a exception on reading stream.