> On March 7, 2017, 9:19 p.m., Vinod Kone wrote: > > 3rdparty/stout/include/stout/base64.hpp > > Lines 181 (patched) > > <https://reviews.apache.org/r/56665/diff/4/?file=1655463#file1655463line181> > > > > why does this function take padding as an argument but not `encode`? > > > > also, it's not clear to me what is the motivation for adding URL safe > > encoder? could you elaborate in the description?
According to RFC 4648, padding is mandatory when using standard Base64. However it is optional when using the URL-safe variant. It states: "Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.". JWT is one of these specs, because it's a JSON Web Signature, and the Base64 variant is explained in https://tools.ietf.org/html/rfc7515#appendix-C - Jan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56665/#review168179 ----------------------------------------------------------- On March 3, 2017, 3 p.m., Jan Schlicht wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/56665/ > ----------------------------------------------------------- > > (Updated March 3, 2017, 3 p.m.) > > > Review request for mesos, Alexander Rojas and Greg Mann. > > > Bugs: MESOS-7001 > https://issues.apache.org/jira/browse/MESOS-7001 > > > Repository: mesos > > > Description > ------- > > Base64 has many variants that use different alphabets for encoding. > "Base 64 Encoding with URL and Filename Safe Alphabet" is a variant > described in RFC 4648. > > > Diffs > ----- > > 3rdparty/stout/include/stout/base64.hpp > 2ac04c4602bc919633a2a480dd2168b7aa301bd7 > 3rdparty/stout/tests/base64_tests.cpp > 32e516861d44c7e3a36e1a29b4d1fe5960684e3b > > > Diff: https://reviews.apache.org/r/56665/diff/4/ > > > Testing > ------- > > make check > > > Thanks, > > Jan Schlicht > >
