commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Rabung <adamrab...@gmail.com>
Subject Re: Commons Codec: base64 "strict" mode?
Date Fri, 04 Dec 2009 16:24:52 GMT
Julius,
My particular problem was the client was not encoding url-safe, and
then sending over http.  The result was I was trying to decode " "
where the client had encoded "+" - so I wasn't get a "+" OR a "-".  A
strict Base64 would have caught this immediately.  I'm not very
familiar w/ the base 64 spec, so your #1 concerns me a little.  Would
it be reasonable for strict mode to reject "abc def", where that space
is literally ascii 32 space?

Paul,
Sounds good.  It would be great if this ability were exposed to the
Base64 input/output streams as well.

I threw together a quick patch (attached).  Not sure how much it will
really help, as I don't know much about the base 64 spec or Apache
coding guidelines (adding checked exceptions to existing methods?),
but it's a start.

Thanks!
Adam

On Thu, Dec 3, 2009 at 4:44 PM, Paul Benedict <pbenedict@apache.org> wrote:
> Base64 could also be given a protected method that allows subclasses
> to handle un-decodable characters. Default op is to do nothing.
>
> protected void handleBadChar(char[] c, int position, other-stuff );
>
> Paul
>
> On Thu, Dec 3, 2009 at 3:38 PM, Julius Davies <juliusdavies@gmail.com> wrote:
>> Hi, Adam,
>>
>> It doesn't currently do that.  Also, Base64 seamlessly decodes
>> URL_SAFE and REGULAR encodings, as well as mixes of the two, even
>> though a mix or URL_SAFE and REGULAR would technically be invalid.
>>
>> I'm not a committer, but I could certainly put together a patch for a
>> strict mode.  Something like this?
>>
>> 1.  If character is not whitespace, and is not valid, throw exception.
>>
>> 2.  If character is inappropriate for our current mode (URL_SAFE or
>> REGULAR), throw exception.
>>
>> 3.  Note:  Personally I think it's too much trouble to detect weird
>> things like === (technically only at most == should ever exist), or
>> characters after ==.  What do you think?
>>
>>
>> ps.  I'd probably do it as a subclass:  Base64Strict extends Base64
>>
>>
>> yours,
>>
>> Julius
>>
>>
>> On Thu, Dec 3, 2009 at 9:05 AM, Adam Rabung <adamrabung@gmail.com> wrote:
>>> Hello,
>>> Currently, Codec skips base64 characters that are outside of the
>>> encode table.  I realize this is perfectly to spec, but I wonder if
>>> other users might appreciate a "strict" mode that throws an exception
>>> when one of these illegal characters are encountered.  For example, I
>>> would love an exception to be thrown here:
>>> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
>>>
>>> My apologies if I'm missing the point or if this functionality already exists,
>>> Adam
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> yours,
>>
>> Julius Davies
>> 250-592-2284 (Home)
>> 250-893-4579 (Mobile)
>> http://juliusdavies.ca/logging.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

Mime
View raw message