xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Redington <m.reding...@ucl.ac.uk>
Subject Re: [Fwd: Re: Moving Base64 in HttpClient to commons-codec]
Date Mon, 03 Feb 2003 21:50:17 GMT

On Monday, February 3, 2003, at 08:37 PM, Ryan Hoegg wrote:

> I've seen these fly by as you have been updating the Bug.  I imagine 
> most of these are Good Things, but I think the Codec people will have 
> concerns about silently ignoring things the RFC encourages us to 
> complain about.  You think we should raise some sort of exception?

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