You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version: v16.8.0 (possibly other versions as well)
Platform: Linux 5.4.0-80-generic Proposal: Harmony enabled binary, packages. #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux (but I think this is irrelevant for this issue
The documentation for 'base64' and 'base64url' both reference RFC 4648, Section 5, but base64 and base64url are two distinct encodings, and the contents of Section 5 states "This encoding may be referred to as "base64url". This encoding should not be regarded as the same as the "base64" encoding and should not be referred to as only "base64". Unless clarified otherwise, "base64" refers to the base 64 in the previous section."
Because of this, it is unclear whether buf.toString('base64') returns base64 or base64url. If it indeed returns base64url, then it is unclear why 'base64url' exists as another encoding option.
I would like to work on this issue and
submit a pull request.
The text was updated successfully, but these errors were encountered:
As the documentation for both of these encoding options read:
Both of them does reference RFC 4648, Section 5, but what to realize here is that the base64 encoding option tells you that it also accepts the "URL and Filename Safe Alphabet" specified specifically in the mentioned section, it doesn't reference that section to explain what exactly the base64 encoding is as a hyperlink has already been provided that leads to the actual explanation of the base64 encoding just above the hyperlink that leads to the section 5 of RFC 4648. That being said it doesn't refer to them being the same option.
The base64url encoding option however references the section 5 of RFC 4648 for a brief explanation of what this encoding exactly is and correctly refers to it as not being the same as the base64 encoding option.
For a difference between the 2 options, at the end of the base64url encoding option's description, it states that it omits the padding which the base64 encoding option doesn't.
📗 API Reference Docs Problem
Location
Section of the site where the content exists
Affected URL(s):
Description
Concise explanation of the problem
The documentation for 'base64' and 'base64url' both reference RFC 4648, Section 5, but base64 and base64url are two distinct encodings, and the contents of Section 5 states "This encoding may be referred to as "base64url". This encoding should not be regarded as the same as the "base64" encoding and should not be referred to as only "base64". Unless clarified otherwise, "base64" refers to the base 64 in the previous section."
Because of this, it is unclear whether
buf.toString('base64')
returns base64 or base64url. If it indeed returns base64url, then it is unclear why 'base64url' exists as another encoding option.submit a pull request.
The text was updated successfully, but these errors were encountered: