Hi,
Without having seen the code, probably for efficiency. Libxml requires 2
passes, first to parse everything into a document, and second to act on the
document parts. This delays execution and raises by a lot memory
requirements. I wouldn't consider coding "string hacks" but proper and
knowledge implementation. Lastly it is about control in programming. Imagine
to have libxml not doing what you want to do and then having to patch it.
Using prepared packages should always be the *last* resort when trying to do
something.
BR,
Nikos
----- Original Message -----
From: "Garth Patil" <[email protected]>
To: <[email protected]>
Sent: Sunday, October 25, 2009 4:12 AM
Subject: Re: rejection of dlr-url field in CDATA
Hi,
After looking in gw/smsbox.c, the answer appears to stem from the
manual parsing of XML done in the get_x_kannel_from_xml() and
get_tag() functions. Does anyone have any idea why these are written
as string hacks and don't use a proper XML parsing library (like
libxml2 which is used elsewhere)? I guess I can add another hack in
get_tag() to deal with the CDATA problem, but it seems like it's
worthwhile porting this to use a proper parser.
Thanks,
Garth
On Sat, Oct 24, 2009 at 6:08 PM, Garth Patil <[email protected]> wrote:
Hi,
I am trying to send a message to the smsbox using the XML format
specified here
(http://kannel.org/download/1.4.3/userguide-1.4.3/userguide.html#POSTXML).
I have attached 2 example documents that should both work properly.
The only difference is that the second one has the dlr-url element
enclosed in a CDATA section. The message in post_test1.xml succeeds,
and the message in post_test2.xml fails with the error "DLR-URL field
misformed, rejected" and produces the following logging statement in
the smsbox log:
2009-10-24 17:56:10 [4572] [3] DEBUG: Status: 400 Answer: <DLR-URL
field misformed, rejected>
Any ideas why using a CDATA section around the dlr-url should cause
parsing of this field to fail? On a related note, NOT using a CDATA
section or otherwise encoding the url causes the XML to be malformed,
so if the parser was being strict (try opening it in Firefox) it
should fail.
Thanks for your help,
Garth
