axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Caching a message byte-for-byte
Date Wed, 13 Jun 2001 14:48:33 GMT
I think you need to verify this with Yuhichi because I think they
ran into a problem a long time ago where their XML parser
wasn't keeping whitespaces and it was throwing off the
digsig verification process.

So, you're telling us that if you use Sax its impossible to
get the XML message byte for byte as it was sent from the
client?  Doesn't seem quite right.


Glen Daniels <> on 06/13/2001 10:28:11 AM

Please respond to

To:   "Axis-Dev (E-mail)" <>
Subject:  Caching a message byte-for-byte

I just want to codify and confirm some discussion which happened on IRC

Storing a message as a series of SAX events will NOT be able to generate
exactly the same sequence of bytes which originally constitued the message.
In particular, consider:

<element xmlns:ns1="url1" attr1="val"     xmlns:ns2="url2"/>

Because SAX splits out the namespace decls into a separate event, there is
no way to reconstruct the attributes of this element in the correct order,
and also there is no way to record the fact that there is extra whitespace
between attr1 and ns2.

Thus, the only way we could see to get the original bytes if you need them
would be to tee the actual bytestream and cache it.  Which we're not, I
believe, going to make a high-priority feature.

DigSig, which has been the oft-used example of needing this, actually only
requires a DOM model of the message, in which inter-element whitespace and
attribute ordering are not significant.

We do still want to have the option of keeping the SAX events around and
recreating the XML in a semantically equivalent form, without lossage (the
"000" -> "0" example), but byte-for-byte isn't really gonna happen.

Glen Daniels
                                Building cool stuff for web developers

View raw message