Tech Rams wrote:
Yes, that is true. This flag does not work if there are NL chars in the
message (anywhere). Thus, you will have to scan the message to find out
if there are NL chars - but the input has to follow some spec - either
they do not have any new lines at all, per
_http://www.w3.org
> So, for example, if the original base64 encoded data
> comes through SMTP, we will have to decode and encode
> it again if we have to put the same value in an XML?
No, precisely the opposite. Anything you get that's legal base64, whatever
the line length, is "legal" XML, and moreover is valid wi
--- Scott Cantor <[EMAIL PROTECTED]> wrote:
>
> There is no spec in XML-land that says base64
> content uses any particular
> line length.
>
So, for example, if the original base64 encoded data
comes through SMTP, we will have to decode and encode
it again if we have to put the same value in an
> I am not sure if you are implying that normalization removes
> line breaks.
Yep. Schema normalization does exactly that.
> AFAIK, normalization just 'joins' adjacent text
> nodes - not dealing with new lines in any way. (I am
> referring to the doc.normalize() call. Please let me know if
>
> Yes, that is true. This flag does not work if there are NL
> chars in the message (anywhere). Thus, you will have to scan
> the message to find out if there are NL chars - but the input
> has to follow some spec -
There is no spec in XML-land that says base64 content uses any particular
line
I am not sure if you are implying that normalization removes line breaks. AFAIK, normalization just 'joins' adjacent text nodes - not dealing with new lines in any way. (I am referring to the doc.normalize() call. Please let me know if you are talking about something else.) -ramsScott Cantor <[
Yes, that is true. This flag does not work if there are NL chars in the message (anywhere). Thus, you will have to scan the message to find out if there are NL chars - but the input has to follow some spec - either they do not have any new lines at all, per http://www.w3.org/TR/xmlschema-2/#base64B
> It also means you have to pre-scan the base64 text to work out what you
> are going to do - which is just plain ugly.
Yeah. The bottom line is that anything that can't consume something with or
without breaks is non-compliant, so clearly OpenSSL is borderline because
the flag is not attractive
Tech Rams wrote:
BTW, OpenSSL has a flag for such cases - BIO_FLAGS_BASE64_NO_NL. Setting
this flag would allow data with no line breaks to be decoded.
I tried using this at one point. It caused yet more problems in that
something *with* a line break at the correct point broke. So if you
h
> BTW, OpenSSL has a flag for such cases -
> BIO_FLAGS_BASE64_NO_NL. Setting this flag would allow data
> with no line breaks to be decoded.
How new is the flag? I ask because it seemed to be a problem in so many
places for quite a while.
-- Scott
BTW, OpenSSL has a flag for such cases - BIO_FLAGS_BASE64_NO_NL. Setting this flag would allow data with no line breaks to be decoded. -ramsScott Cantor <[EMAIL PROTECTED]> wrote: > While wrapping at 76 appears to do neither good nor> harm in the XML world, I still "feel" this is "ugly".> > La
> While wrapping at 76 appears to do neither good nor
> harm in the XML world, I still "feel" this is "ugly".
>
> Large autogenerated XML docs usually contain no
> linebreaks and appear on one line.
> Except when you sign them with Apache xmlsec, now
> they get a few extra linebreaks...
>
> I per
Hello...
While doing interoperability experiments with XML documents
containing digital signatures created with the Apache xmlsec
project libraries (=the libraries contained in the Java WSDP
package), I noticed a difference to other providers
output.
Base64 coded components, e.g. the Modulus of
13 matches
Mail list logo
