ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Redundant names space removal when Serializing - AXIOM
Date Mon, 21 Nov 2011 19:11:30 GMT
Eran & Aleksander,

These are interesting discussions, but they have nothing to do with
the problem. I think that you didn't read the thread carefully from
the beginning. There is no node being detached, there is no
serialization of a subtree, there is no namespace context being lost
and there is no generation of malformed XML anywhere.

The scenario is this: Axiom is used to parse a document that contains
a redundant namespace declaration, i.e. a namespace declaration for
which another namespace declaration with the same prefix and URI is
already in scope on the parent element. In Charith's sample this is
the xmlns:xsi declaration that is present on the SOAP envelope and on
the SAML assertion.

The current behavior of Axiom is as follows (and it has always been
since I started to work on Axiom, but that was when colour TV already
existed...):
* The object model will contain an object for each namespace
declarations appearing in the original document, even for redundant
ones.
* The serializer performs namespace repairing and (in addition to
generating extra namespace declarations where necessary) skips the
serialization of redundant namespace declarations (as defined above).

>From the perspective of the core XML specs, this is a perfectly valid
thing to do because the resulting XML document is well formed and the
namespace context of each and every element is strictly preserved.

As Charith pointed out, the SAML assertion is signed. As you know,
before an element is signed, it is first canonicalized. This is where
the real question is: is any of the C14N schemes sensitive to the
removal of redundant namespace declarations? I don't know the C14N
specs well enough to answer that question, but I've seen that these
specs make provisions to preserve the namespace context of the element
and also define an algorithm to remove redundant namespace
declarations (search for "superfluous" or "unnecessary" namespace
declarations through the specs).

Andreas

On Mon, Nov 21, 2011 at 18:29, Eran Chinthaka Withana
<eran.chinthaka@gmail.com> wrote:
> Hi Charith,
> Trying to understand this still.
> From the example, seems like the output XML does not contain the namespace
> declaration related to saml prefix. Who removes it from the original message
> and put it inside the output message? Thats the important question I think.
> Andreas, even though there are no specs defining the "right" behavior the
> rule I always went with Axiom was the idea of namespace context. If a node
> gets removed from a tree it should have the namespace context. If it gets
> added to a new tree, then this context should fuse with the new tree. From
> the look of this error it is not happening.
> Also, as Andreas mentioned Axiom never produces mal-formed xml (thanks to
> our parsers mainly). But seems like it does. Charith, can you please try to
> dig a little bit deeper?
> (Disclaimer: last time I saw Axiom code was when we had black and white TVs
> :) My knowledge on this can be old but I assume concepts have not changed)
> Thanks,
> Eran Chinthaka Withana
>
>
> On Sun, Nov 20, 2011 at 8:31 PM, Charith Wickramarachchi
> <charith.dhanushka@gmail.com> wrote:
>>
>> Hi ,
>>
>> Looked more in to the details of whats happening. So here the problem is
>> the element that have this redundant names space is the <saml:Assertion ...
>> element which is a signed one.
>>
>>
>> The incoming message to synapse looks like this.
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>    <soapenv:Header>
>>       <oas:Security>
>> <saml:Assertion ....
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...
>> </saml:Assertion>
>> </oas:Security>
>>    </soapenv:Header>
>> ...........................
>> </soapenv:Envelope>
>>
>>
>> and output is like
>>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>    <soapenv:Header>
>>       <oas:Security>
>> <saml:Assertion ...> ... </saml:Assertion>
>> </oas:Security>
>>    </soapenv:Header>
>>
>>
>> So in this case isn't it wrong to do this kind of optimizations ?
>>
>> thanks,
>> Charith
>>
>>
>>
>>
>>
>> On Mon, Nov 21, 2011 at 8:50 AM, Charith Wickramarachchi
>> <charith.dhanushka@gmail.com> wrote:
>>>
>>> Hi ,
>>>
>>> This is an issue with the BE service. When the message comes to synapse
>>> from the client. In its SOAP Message it has same name space declared at two
>>> levels.
>>>
>>> At Envelope level and and inside a header. So as a result when message go
>>> through synapse  it will omit this redundant names space declaration.
>>> But BE service will fail to process this header due to  missing
>>> namesspace. So its due to BEs xml phaser assumes that headers are self
>>> contained and they do not see the namesspace defined at Envelope level.
>>>
>>> thanks,
>>> Charith
>>>
>>> On Sun, Nov 20, 2011 at 11:12 PM, Sanjiva Weerawarana
>>> <sanjiva@opensource.lk> wrote:
>>>>
>>>> "So when synapse forward them  to the BE service they get omitted as
>>>> they are defined at SOAP Envelope level."
>>>> Maybe Synapse is not serializing the headers properly?
>>>> Sanjiva.
>>>>
>>>> On Sun, Nov 20, 2011 at 10:55 PM, Andreas Veithen
>>>> <andreas.veithen@gmail.com> wrote:
>>>>>
>>>>> Axiom never produces malformed XML. Who said that??
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Sun, Nov 20, 2011 at 17:59, Sanjiva Weerawarana
>>>>> <sanjiva@opensource.lk> wrote:
>>>>> > Isn't that a bug?
>>>>> > If I declare an NS at the Envelope node then that cannot be removed
>>>>> > if
>>>>> > anyone inside uses it. If I'm serializing only the Header element(s)
>>>>> > then
>>>>> > any in scope namespaces must be available and worst case every
>>>>> > element will
>>>>> > re-serialize them. However under no condition is it correct to
>>>>> > serialize a
>>>>> > child element and end up with malformed XML!
>>>>> >
>>>>> > Sanjiva.
>>>>> >
>>>>> > On Sat, Nov 19, 2011 at 10:28 PM, Andreas Veithen
>>>>> > <andreas.veithen@gmail.com> wrote:
>>>>> >>
>>>>> >> Assuming that the namespace in question is not the SOAP envelope
>>>>> >> namespace, instead of hacking Axiom, wouldn't it be easier to
remove
>>>>> >> the namespace declaration from the SOAP envelope (so that it
will be
>>>>> >> serialized in the SOAP header block)?
>>>>> >>
>>>>> >> Andreas
>>>>> >>
>>>>> >> On Sat, Nov 19, 2011 at 06:11, Charith Wickramarachchi
>>>>> >> <charith.dhanushka@gmail.com> wrote:
>>>>> >> > Hi Andreas,
>>>>> >> >
>>>>> >> > Issue was this causes an Error in a 3rd party web-service
engine
>>>>> >> > when
>>>>> >> > processing some soap headers.
>>>>> >> >
>>>>> >> > Scenario is this. Synapse get a soap request which contains
some
>>>>> >> > redundant
>>>>> >> > namespace declarations at header level which are internally
used
>>>>> >> > inside
>>>>> >> > the
>>>>> >> > headers. So when synapse forward them  to the BE service
they get
>>>>> >> > omitted as
>>>>> >> > they are defined at SOAP Envelope level.
>>>>> >> >
>>>>> >> > BE services header processor incorrectly assumes that headers
are
>>>>> >> > self
>>>>> >> > contained so this causes an error.
>>>>> >> >
>>>>> >> > I was wondering it may make scene to make it configurable 
as if
>>>>> >> > we
>>>>> >> > think
>>>>> >> > of  synapse point of view omitting redundant namespaces
may not be
>>>>> >> > a
>>>>> >> > good
>>>>> >> > idea sometimes. Specially integrating with legacies like
this.
>>>>> >> > WDYT ? (
>>>>> >> > I do
>>>>> >> > agree that this in pure AXIOM point of view its the correct
thing
>>>>> >> > to do
>>>>> >> > as
>>>>> >> > it will reduce the data content that is written to the
wire etc..
>>>>> >> > )
>>>>> >> >
>>>>> >> > Can please you point me to a place where this is done ?
So that i
>>>>> >> > can
>>>>> >> > hack
>>>>> >> > the code for the time being for my self and later provide
a patch
>>>>> >> > if
>>>>> >> > devs
>>>>> >> > are ok with my above idea.
>>>>> >> >
>>>>> >> > thanks,
>>>>> >> > Charith
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Nov 18, 2011 at 3:55 PM, Andreas Veithen
>>>>> >> > <andreas.veithen@gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> No, the namespace repairing performed by the serialize
and
>>>>> >> >> serializeAndConsume methods is not configurable.
>>>>> >> >>
>>>>> >> >> What is the use case for preserving a redundant namespace
>>>>> >> >> declaration
>>>>> >> >> on a SOAP header?
>>>>> >> >>
>>>>> >> >> Andreas
>>>>> >> >>
>>>>> >> >> On Fri, Nov 18, 2011 at 03:23, Charith Wickramarachchi
>>>>> >> >> <charith.dhanushka@gmail.com> wrote:
>>>>> >> >> > Hi devs ,
>>>>> >> >> >
>>>>> >> >> > When we serialize a OMElement axiom will omit
redundant
>>>>> >> >> > namesspace
>>>>> >> >> > declarations by default. Is it possible to disable
this
>>>>> >> >> > behavior ?
>>>>> >> >> > In my case i want to keep the redundant namesspace
declarations
>>>>> >> >> > in
>>>>> >> >> > SOAP
>>>>> >> >> > headers.
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > thanks,
>>>>> >> >> > Charith
>>>>> >> >> >
>>>>> >> >> > --
>>>>> >> >> > Charith Dhanushka Wickramarachchi
>>>>> >> >> > http://charithwiki.blogspot.com/
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> ---------------------------------------------------------------------
>>>>> >> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> >> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Charith Dhanushka Wickramarachchi
>>>>> >> > http://charithwiki.blogspot.com/
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> >> For additional commands, e-mail: dev-help@ws.apache.org
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Sanjiva Weerawarana, Ph.D.
>>>>> > Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>>> > http://www.opensource.lk/
>>>>> > Founder, Chairman & CEO; WSO2; http://wso2.com/
>>>>> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
>>>>> > Member; Apache Software Foundation; http://www.apache.org/
>>>>> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>> >
>>>>> > Blog: http://sanjiva.weerawarana.org/
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: dev-help@ws.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2; http://wso2.com/
>>>> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>
>>>
>>>
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>
>

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


Mime
View raw message