commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [codec] RE: Base64.java
Date Tue, 04 Feb 2003 20:19:09 GMT

I agree with you up until the last point.

Rather than an obscure and irritating boolean argument on the end, just
offer a different name.

public static byte[] decode(byte[] data);
public static byte[] decodeChunked(byte[] data);

[bear in mind decodeChunked may be a bad name. I'm just copying :) ]

Hen

On Tue, 4 Feb 2003, Jeffrey Dever wrote:

> There does not seem to be much choice other than overloading the method
> signatures:
> public static byte[] decode(byte[] data);
> public static byte[] decode(byte[] data, boolean chunk);
>
> Jandalf.
>
>
> O'brien, Tim wrote:
>
> >Here's Martin's post on rpc-dev re: cr/lf:
> >http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc-dev@xml.apache.org&m
> >sgNo=713
> >
> >Here's some observations, I've copied individuals from both the xml-rpc and
> >the httpclient project.  It all boils down to using Base64 encoding in the
> >context of two different RFCs, 2045 and 2616.  I believe that we can come to
> >an agreement here by adding some option flags to the method signatures.
> >
> >*** XML-RPC facts:
> >
> >1. I believe that XML-RPC is using Base64 in the context of RFC 2045 which
> >requires Base64 content to be encoded in 76 character "chunks" separated by
> >a newline character.  The traling newline character is added to "terminate"
> >the final chunk.
> >
> >2. XML-RPC is also adhereing to the requirement to discard all whitespace
> >when decoding base64 data.
> >
> >3. XML-RPC is not complying with the requirement to convert text to
> >canonical form - replacing "text line breaks" with "CRLF sequences".
> >
> >*** HTTPClient facts:
> >
> >1. HttpClient's usage of Base64 does not create chunks of 76 characters
> >separated by newlines - as this would interfere with HTTP headers.
> >
> >2. HttpClient's Base64 doesn't discard whitespace because in the context of
> >usage, no whitespace is added to the encoded output - see #1
> >
> >
> >
> >** Here is RFC 2045 Multipurpose Internet Mail Extensions:
> >http://www.ietf.org/rfc/rfc2045.txt
> >
> >2045 requirement 1: RFC 2045 on converting text material to canonical form:
> >"Care must be taken to use the proper octets for line breaks if base64
> >encoding is applied directly to text material that has not been converted to
> >canonical form.  In particular, text line breaks must be converted into CRLF
> >sequences prior to base64 encoding.  The important thing to note is that
> >this may be done directly by the encoder rather than in a prior
> >canonicalization step in some implementations."
> >
> >2045 requirement 2: In terms of RFC 2045, requirement for "chunking" and
> >ignoring white space when decoding: "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."
> >
> >
> >** Here is RFC 2616 HTTP 1.1 which talks about base64 of an MD5 digest in a
> >header: http://www.ietf.org/rfc/rfc2616.txt?number=2616
> >
> >"Conversion of all line breaks to CRLF MUST NOT be done before computing or
> >checking the digest: the line break convention used in the text actually
> >transmitted MUST be left unaltered when computing the digest."
> >
> >"Note: while the definition of Content-MD5 is exactly the same for HTTP as
> >in RFC 1864 for MIME entity-bodies, there are several ways in which the
> >application of Content-MD5 to HTTP entity-bodies differs from its
> >application to MIME entity-bodies. One is that HTTP, unlike MIME, does not
> >use Content-Transfer-Encoding, and does use Transfer-Encoding and
> >Content-Encoding. Another is that HTTP more frequently uses binary content
> >types than MIME, so it is worth noting that, in such cases, the byte order
> >used to compute the digest is the transmission byte order defined for the
> >type. Lastly, HTTP allows transmission of text types with any of several
> >line break conventions and not just the canonical form using CRLF."
> >
> >
> >--------
> >Tim O'Brien
> >
> >
> >
> >>-----Original Message-----
> >>From: Jeffrey Dever [mailto:jsdever@sympatico.ca]
> >>Sent: Tuesday, February 04, 2003 10:16 AM
> >>To: O'brien, Tim
> >>Cc: 'Martin Redington'; rhoegg@isisnetworks.net
> >>Subject: Re: Base64.java
> >>
> >>
> >>Http is very cr/lf aware. We use Base64 for encoding/decoding values
> >>that are added to headers which are always appended with a cr/lf as a
> >>value is not to contain the line delimiter.
> >>
> >>Where (which) rfc does it state the trailing cr/lf?
> >>
> >>Jandalf.
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message