Re: PATCH: Proper namespaces handling in DJabberd
Em Qui, 2009-10-29 às 14:11 -0300, Daniel Ruoso escreveu: Em Sex, 2009-07-03 às 10:53 -0700, Brad Fitzpatrick escreveu: Your patch doesn't include new tests demonstrating the problem or the fix. We never really accept any patch that's a bunch of changed code with no test changes. Ok, after some time, I finally implemented a specific test to demonstrate the problem of namespace handling, and follows an updated patch (based on the head of http://github.com/apparentlymart/djabberd). Sorry if I seem inconvenient... but... did anyone notice the modified patch? daniel
Re: PATCH: Proper namespaces handling in DJabberd
Your patch doesn't include new tests demonstrating the problem or the fix. We never really accept any patch that's a bunch of changed code with no test changes. On Thu, Jul 2, 2009 at 5:46 AM, Daniel Ruoso dan...@ruoso.com wrote: Em Qua, 2009-06-10 às 11:59 -0700, Martin Atkins escreveu: Thanks for the patch. It does seem like this is a problem we should address. Martin, Is there any planning of when will this patch be integrated? daniel
Re: PATCH: Proper namespaces handling in DJabberd
Em Qua, 2009-06-10 às 13:00 -0700, Martin Atkins escreveu: And you are sending this element as a direct child of a message stanza? Yes, it is a direct child of the stanza element. Can you share some code that illustrates the problem? Unfortunally, I only have code that is integrated with the system. But I was able to reproduce it with netcat... I'm surprised to hear that namespaces aren't working since we use them as part of the switching mechanism to determine the type of an iq stanza. Ok, namespaces are partly working. If you only use namespaces without using prefixes, it works fine. The problem is when you use prefixes to declare the namespaces of the elements, which, when you have unqualified elements in the document, is actually a requirement. I'm happy to have a whack at writing a test for this, but right now I'm not entirely sure what I'm testing; we already have some tests that use namespaces, such as the vcard one you made minor alterations to in your patch, so I don't know what additional test we need to catch the bug you've found. The test is to send a document that use namespace with prefixes, and have the namespaces with prefixes in the other side. The example XML message I sent illustrates the problem in detail. daniel
Re: PATCH: Proper namespaces handling in DJabberd
Daniel Ruoso wrote: Just try to send any XML with namespace information and you should see it happening, like: SOAP-ENV:Envelope xmlns:SOAP-ENV=... SOAP-ENV:Body SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringBla bla bla/faultstring /SOAP-ENV:Fault /SOAP-ENV:Body /SOAP-ENV:Envelope would become Envelope xmlns=... SOAP-ENV=... Body Fault faultcodeSOAP-ENV:Server/faultcode faultstringBla bla bla/faultstring /Fault /Body /Envelope The problems here are: * xmlms:SOAP-ENV became simply SOAP-ENV... which is a non-existant attribute * faultcode and faultstring were unqualified elements and now are declared as being of the SOAP-ENV namespace * renaming the prefixes is not a recommended practice, and, in fact, you need to understand the specific XSD to do it, since QName types (the SOAP-ENV:Server value) care about the prefix. While I agree that there are some bugs here, it seems like even if we did preserve the prefixes your faultcode and faultstring elements would be in the wrong namespace, because the default namespace within the XMPP stream is jabber:client, jabber:server or whatever. Is there something else we need to do here to make faultcode and faultstring work as expected? I'm not really familiar with SOAP iself, let alone SOAP over XMPP, so if I'm misunderstanding what's going on here please let me know... I just want to make sure that we are indeed addressing all of the prefix-related problems.
