base64 Incorrect Padding

[Brandon Fredericks]

I did a search within this group, but couldn't find any information on
this.

I am sending base64 encoded data as the content over http using
urllib2 urlopen. When I receive the data and attempt to decode it, I
get an "Incorrect Padding" error. Is there a simple way to fix this? A
better way to send and receive the data possibly (using base64 of
course)?

 

[Peter Otten]

I did a search within this group, but couldn't find any information on
this.

I am sending base64 encoded data as the content over http using
urllib2 urlopen. When I receive the data and attempt to decode it, I
get an "Incorrect Padding" error. Is there a simple way to fix this? A
better way to send and receive the data possibly (using base64 of
course)?

Have the server send some known data. Read it with urllib2.urlopen().
Compare with that same data that you encoded locally. What are the
differences?

Peter

 

[MRAB]

I did a search within this group, but couldn't find any information on
this.

I am sending base64 encoded data as the content over http using
urllib2 urlopen. When I receive the data and attempt to decode it, I
get an "Incorrect Padding" error. Is there a simple way to fix this? A
better way to send and receive the data possibly (using base64 of
course)?

Base-64 encodes 3 bytes (echo in the range 0-255) to 4 bytes (each in a
more restricted range). The length of the output is _always_ a multiple
of 4 (ignoring whitespace); the method adds extra padding bytes (ASCII
'=') to ensure that this is the case if the length of the input isn't a
multiple of 3.

So, if decoding raises an "Incorrect Padding" error then strip out any
whitespace and append extra ASCII '=' to make its length a multiple of
3, then try decoding again. (Or you could just repeatedly add one pad
character and retry, up to 3 times.)

 

[Max Erickson]

Base-64 encodes 3 bytes (echo in the range 0-255) to 4 bytes
(each in a more restricted range). The length of the output is
_always_ a multiple of 4 (ignoring whitespace); the method adds
extra padding bytes (ASCII '=') to ensure that this is the case
if the length of the input isn't a multiple of 3.

So, if decoding raises an "Incorrect Padding" error then strip
out any whitespace and append extra ASCII '=' to make its length
a multiple of 3, then try decoding again. (Or you could just
repeatedly add one pad character and retry, up to 3 times.)

The length of the encoded string should be a multiple of 4 (as you
state in the second sentence of your post), not a multiple of 3.


max

 

[MRAB]

The length of the encoded string should be a multiple of 4 (as you
state in the second sentence of your post), not a multiple of 3.

Oops, correct!

 

[bfrederi]

So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?

 

[MRAB]

So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?

I think that when it says Base-64 it's talking about the byte values
used for the encoding.

 

[Gabriel Genellina]

So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?

It doesn't matter, a base64-encoded string contains only ASCII characters.
How are you encoding the text? base64.b64encode does the padding for you,
so you don't have to worry about that. Do as P. Otten suggests, try to
send some known text and see what you actually get on the server. Most
likely you'll find another problem (like trying to decode the complete
HTTP response instead of just the entity body, or some other stupid
mistake ).