xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Date Mon, 03 Feb 2003 22:33:00 GMT
I think I'm going to back off any further changes as it looks like this 
has turned into an Apache-wide thing now:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=23792

Tim O'Brien says there are 35 (!) active classes throughout Apache using 
this code.  After the dust settles we should probably move further 
discussion of this to the Commons-dev list so the Codec committers can 
participate.

Anyone have input on how to introduce the runtime dependency?  Daniel's 
point about the classloader keeps nagging at me.  Perhaps include a link 
to the Codec JAR on our installation instructions?

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Martin Redington wrote:

> Well, here is what the RFC says:
>
> RFC 2045
>
> from section 6.8
>
> The encoded output stream must be represented in lines of no more
>    than 76 characters each.  All line breaks or other characters not
>    found in Table 1 must be ignored by decoding software.  In base64
>    data, characters other than those in Table 1, line breaks, and other
>    white space probably indicate a transmission error, about which a
>    warning message or even a message rejection might be appropriate
>    under some circumstances.
>
> I think that the last sentence is equivalent to MAY in RFC-speak, so 
> the patch "as is" makes us RFC-compliant.
>
> I think the most conservative (least change) approach, and my 
> instinctive reaction is to ignore non base64 chars for now (which is 
> no worse than the current non-RFC compliant version) and see if anyone 
> files a bug.
>
> OTOH, non-base64 characters are almost certain to be transmission 
> errors, so you may well be doing the end-user a big favour by throwing 
> an exception with a clear message.
>
> I believe there's a comment in the patched code indicating where the 
> exception should go, so if you favour the latter approach, just stick 
> one in ...
>




Mime
View raw message