axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: Caching a message byte-for-byte
Date Wed, 13 Jun 2001 15:36:53 GMT
Actually, if you use DOM you can't get it back either .. the
order of attributes is not specified; its impl defined. I
personally don't think this is a problem, as long as Axis
has some way for a handler (or whatever) to intercept at a
lower level too (ala the EnvelopeEditor stuff in Apache SOAP).


----- Original Message -----
From: "Doug Davis" <>
To: <>
Sent: Wednesday, June 13, 2001 10:48 AM
Subject: Re: Caching a message byte-for-byte

> 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.
> -Dug
> Glen Daniels <> on 06/13/2001 10:28:11 AM
> Please respond to
> To:   "Axis-Dev (E-mail)" <>
> cc:
> Subject:  Caching a message byte-for-byte
> I just want to codify and confirm some discussion which happened on IRC
> yesterday.
> 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
> 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
> Macromedia
>                                 Building cool stuff for web developers

View raw message