Adam, Attach all patches to a JIRA ticket so your effort isn't lost. If one doesn't exist, just go create it.
Paul On Fri, Dec 4, 2009 at 10:24 AM, Adam Rabung <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >>> -- >>> yours, >>> >>> Julius Davies >>> 250-592-2284 (Home) >>> 250-893-4579 (Mobile) >>> http://juliusdavies.ca/logging.html >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
