New issue
Advanced search Search tips

Issue 609856 link

Starred by 2 users
Status: Started
Owner:
peter@chromium.org
Cc:
eroman@chromium.org
haraken@chromium.org
esprehn@chromium.org
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Base64(Url) operations in Blink should use the //base implementations

Project Member Reported by peter@chromium.org, May 6 2016 
We currently have encoding and decoding routines for the base64 and URL-safe base64 encodings living in WTF.

third_party/WebKit/Source/wtf/text/Base64.h

They duplicate logic, don't support the full spectrum of encoding and decoding policies (e.g. one might not want to include trailing padding) and have a fair amount of unused APIs.

Let's change it to wrap the //base version instead.

Comment 1 by esprehn@chromium.org, May 6 2016 

I think we only want to do this if we can make it work without a string
copy. That'll require making the base thing accept the char type as a
template param so we can branch on is8bit() before invoking the converter.
Base also assumes strings are utf8, but wtf is either latin1 or utf16. We
need to make sure this doesn't require a conversion to utf8 as well.

Comment 2 by peter@chromium.org, May 6 2016 

The //base version takes a StringPiece, so we do not need any more data copies than we do today.

The //base version does not make any specific assumptions about the encoding of the input.

Comment 3 by esprehn@chromium.org, May 6 2016 

The return value will result in a string copy since it can't use our StringBuilder. Also are you sure it's okay to take a utf16 string and reinterpret_cast it to char and base64 encode that?

Comment 4 by benhenry@google.com, Jan 11 

You started fixing this bug over two years ago. Are you still working on it?
►

Sign in to add a comment