This repository has been archived by the owner on May 31, 2021. It is now read-only.
Fix wrong SCGI XML-RPC body length calculation method #635
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix wrong XML-RPC body length calculation method which results in SCGI calls failing when multibyte characters are included.
Description
I discovered that flood calculates XML-RPC body length of an SCGI call simply by using String.prototype.length. This works ok when all payload is consist of single-byte characters.
However, when any multibyte character is included in xml payload, it miscalculate body length as JavaScript's string is UTF-16 and every UTF-8 multibyte characters are single-byte in UTF-16. So while String.prototype.length reports that the length of a UTF-8 character is 1, it may be 2-4 bytes when encoded in UTF-8, which causes rTorrent's XML-RPC server to misbehave.
[Error: XML-RPC fault: Call XML not a proper XML-RPC call. Call is not valid XML. Invalid XML "content". Problem with token at '<...': unclosed token]
This error is thrown when UTF-8 multibyte character is included in XML body, as current implementation of SCGI call builder reports shorter body length than its actual length.
I fixed this issue by calculating body length properly using Node's Buffer.byteLength function, which returns real byte length of UTF-8 encoded string.
Related Issue
#164 #196
I think changes in #196 may be reverted, but not tested.
Motivation and Context
I faced this issue when I tried to add torrents with download path including CJK characters. I wasn't able to use flood since my hard drive is full of directories containing UTF-8 multibyte characters and flood couldn't handle it.
This PR fixes issues with CJK character handling.
How Has This Been Tested?
I'm running the modified source on my machine for several days with bunch of torrents with multibyte character path. No problem so far.
Types of changes
Checklist: