tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Sch├Ânhaber <tomcat-...@list-post.mks-mail.de>
Subject Re: buildbot failure in ASF Buildbot on tomcat-trunk
Date Wed, 28 Mar 2012 19:02:44 GMT
28.03.2012 19:42, Konstantin Kolinko:

> 2012/3/28 Markus Sch├Ânhaber <tomcat-dev@list-post.mks-mail.de>:
>> 28.03.2012 18:31, Filip Hanik (mailing lists):
>>
>>> Is it my email client, or are some of these emails empty?
>>
>> It's probably your client. That's the body of the mail you responded to:
[...]

> Viewing the source of the message, it is encoded in base64.
> 
> What is a bit strange it is that the base64 chars come in two blocks
> of different width, and there is "=" at the end of the last line of
> first block. I doubt that the equals sign is allowed in the middle of
> data.

You're right, I didn't notice this.
Seems like the list software simply glues the base64-encoded footer to
the existing message.
I took a (just superficial) look at RFC 4648 and didn't see that this is
explicitly forbidden but from this
http://tools.ietf.org/html/rfc4648#section-3.1
| 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.

it might - IMO - be deduced that the particular input we have here, is
not a valid base64-encoded string (the line-length of 72 chars in the
footer block seems suspicious too).

BTW: If one feeds the complete body of the mail to python's
base64.b64decode the footer will be missing while thunderbird decodes
that as well.

Bottom line: Regardless whether or not it really is violating the spec
to glue two base64-encoded strings together and expect the result to be
a new, valid, base64-encoded string - in practice, at least, it seems to
be a bad idea.

-- 
Regards
  mks

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


Mime
View raw message