Smalltalk › Instantiations

SstBase64Coder posible bug

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Leo O.

SstBase64Coder posible bug

Hi all,

I was working with SstBase64Coder and i found a potential mistaken behavior. When you encode a stream larger than x bytes, the implementation adds CR/LF. This is correct only in a few scenarios (smtp and pem). The ansi should be not to add any control characters as the RFC says:

http://tools.ietf.org/html/rfc4648#page-3

3.1. Line Feeds in Encoded Data

MIME [4] is often used as a reference for base 64 encoding. However,

MIME does not define "base 64" per se, but rather a "base 64 Content-

Transfer-Encoding" for use within MIME. As such, MIME enforces a

limit on line length of base 64-encoded data to 76 characters. MIME

inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating

that it is "virtually identical"; however, PEM uses a line length of

64 characters. The MIME and PEM limits are both due to limits within

SMTP.

Implementations MUST NOT add line feeds to base-encoded data unless

the specification referring to this document explicitly directs base

encoders to add line feeds after a specific number of characters.

PD: The class could be modified to accepts configurations of this behavior.

Bye

Leonardo

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

John O'Keefe-3

Re: SstBase64Coder posible bug

Leonardo -

Thanks for identifying this problem. I will put this on the list of things to fix for our 2014 release.

On Monday, July 29, 2013 6:30:32 PM UTC-4, Leo O. wrote:

Hi all,
I was working with SstBase64Coder and i found a potential mistaken behavior. When you encode a stream larger than x bytes, the implementation adds CR/LF. This is correct only in a few scenarios (smtp and pem). The ansi should be not to add any control characters as the RFC says:

http://tools.ietf.org/html/rfc4648#page-3
3.1. Line Feeds in Encoded Data

MIME [4] is often used as a reference for base 64 encoding. However,
MIME does not define "base 64" per se, but rather a "base 64 Content-
Transfer-Encoding" for use within MIME. As such, MIME enforces a
limit on line length of base 64-encoded data to 76 characters. MIME
inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
that it is "virtually identical"; however, PEM uses a line length of
64 characters. The MIME and PEM limits are both due to limits within
SMTP.

Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.

PD: The class could be modified to accepts configurations of this behavior.
Bye
Leonardo

John O'Keefe-3

Re: SstBase64Coder posible bug

In V8.6.1 SstBase64Coder and AbtBase64Coder have been (almost invisibly) replaced by Base64Coder and its subclasses (one for each encoding mode). In particular, SstBase64Coder new will answer an instance of Base64CoderMime - the class that most closely matches the operation of SstBase64Coder. Coose a different Base64Coder[xxx] class for different behavior.

John

On Wednesday, July 31, 2013 11:08:29 AM UTC-4, John O'Keefe wrote:

Leonardo -

Thanks for identifying this problem. I will put this on the list of things to fix for our 2014 release.

On Monday, July 29, 2013 6:30:32 PM UTC-4, Leo O. wrote:
Hi all,
I was working with SstBase64Coder and i found a potential mistaken behavior. When you encode a stream larger than x bytes, the implementation adds CR/LF. This is correct only in a few scenarios (smtp and pem). The ansi should be not to add any control characters as the RFC says:

<a href="http://tools.ietf.org/html/rfc4648#page-3" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4648%23page-3\46sa\75D\46sntz\0751\46usg\75AFQjCNENtuh8m2sYO0BGkC5YTxVQtOKbuQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4648%23page-3\46sa\75D\46sntz\0751\46usg\75AFQjCNENtuh8m2sYO0BGkC5YTxVQtOKbuQ';return true;">http://tools.ietf.org/html/rfc4648#page-3
3.1. Line Feeds in Encoded Data

MIME [4] is often used as a reference for base 64 encoding. However,
MIME does not define "base 64" per se, but rather a "base 64 Content-
Transfer-Encoding" for use within MIME. As such, MIME enforces a
limit on line length of base 64-encoded data to 76 characters. MIME
inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
that it is "virtually identical"; however, PEM uses a line length of
64 characters. The MIME and PEM limits are both due to limits within
SMTP.

Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.

PD: The class could be modified to accepts configurations of this behavior.
Bye
Leonardo