RE: Base64 encoding/decoding

It is just one =.

My app (and I tested with Scott Klements too) ends like this:

WJrNzV=

But online encoders end with this:

WJrNzU=

Both though do decode to the proper value. But the first seems to be
causing issues with the standard open source Apache library decoder.

Bradley V. Stone
BVSTools - www.bvstools.com
eRPG SDK - www.erpgsdk.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of
J.Beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx
Sent: Tuesday, April 22, 2008 8:56 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Base64 encoding/decoding


Hello Bradley,

Are you sure the encoded data ends with two '=' characters?

According to RFC 3548 (<http://tools.ietf.org/html/rfc3548>) there are
three possibilities for padding:
- Data is an integral multiple of 24 bits: No padding needed
- Final quantum of input is 8 bits: leads to two characters and two '='
characters for padding
- Final quantum of input is 16 bits: leads to three characters
and one '='
character for padding

In the second case the character before the '==' should consist of the
last two bits of the final byte of the input, with four zero bits added.
So that could be 000000 (0 = A), 010000 (16 = Q), 100000 (32 = g) of
110000 (48 = w).

Joep Beckeringh


rpg400-l-bounces@xxxxxxxxxxxx wrote on 22-04-2008 15:18:43:

I'm working with a customer who is working with a web service that

requires

basic authentication.

The RPG application worked until the web service was updated somehow,

and

now it's returning an unauthorized error message.

We checked the authorization data being sent. It translates back to

exactly

what it should be using an online base64 decoder.

The funny thing is, when we use an online base64 encoder, it results in

the

same encoded data as the RPG app except for the last character (before

two

=='s) which is a U instead of a V.

Both values DO decode back to the orignal data.

The admins of the web service are saying that the encoded data is wrong.
Their proof is when they encode it, it's different than what we're

sending.

We claim it's working find because decoding either of the

values results
in

the proper values.

Any ideas?

Bradley V. Stone
BVSTools - www.bvstools.com
eRPG SDK - www.erpgsdk.com

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.