commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (O'brien, Tim)
Subject [codec] RE:
Date Tue, 04 Feb 2003 17:41:27 GMT
Here's Martin's post on rpc-dev re: cr/lf:

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:

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

** Here is RFC 2616 HTTP 1.1 which talks about base64 of an MD5 digest in a

"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 [] 
> Sent: Tuesday, February 04, 2003 10:16 AM
> To: O'brien, Tim
> Cc: 'Martin Redington';
> Subject: Re:
> 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:
For additional commands, e-mail:

View raw message