Webmaster Forum / ColdFusion / Advanced Techniques / May 2008

your xml is ill formed. look at the first few lines of it.

It is the automatically generated XML from the chttp request response from
Authorize.net.  For an example, if i dump cfhttp.fileContent I get:

<?xml version="1.0" encoding="utf-8"?><ARBCreateSubscriptionResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><refId>dus6073</refId><messages>
<resultCode>Error</resultCode><message><code>E00012</code><text>You have
submitted a duplicate of Subscription 277440. A duplicate subscription will not
be created.</text></message></messages></ARBCreateSubscriptionResponse>

I am having no luck with this.  Do you see any problem with the sample XML above?

If i dump cfhttp.fileContent it outputs the above xml.  If i
<cfoutput>#cfhttp.fileContent#</cfoutput>, it only outputs the text in the
element nodes.  That's what i would expect it to do but does it have anything
to do with my problem?

Here is a url:  https://midas.jnet.us/dc/cf_aim/testarb.cfm
It is CF8.
Here is the source:
<cfxml variable="XMLSubscriptionRequest">
    <?xml version="1.0" encoding="utf-8"?>
    <ARBCreateSubscriptionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
        <merchantAuthentication>
            <name>xasdfasdfpJD</name>
            <transactionKey>xsdafdsafasdfjrx6</transactionKey>
        </merchantAuthentication>
        <refId>sample</refId>
        <subscription>
            <name>ProPlanner Subscription</name>
            <paymentSchedule>
                <interval>
                    <length>12</length>
                    <unit>months</unit>
                </interval>
                <startDate>2008-04-20</startDate>
                <totalOccurrences>9999</totalOccurrences>
            </paymentSchedule>
            <amount>500.00</amount>
            <payment>
                <creditCard>
                    <cardNumber>4111111111111111</cardNumber>
                    <expirationDate>2008-12</expirationDate>
                </creditCard>
            </payment>
            <customer>
                <id>test0001</id>
                <email>test@abc.com</email>
                <phoneNumber>555-555-5555</phoneNumber>
            </customer>
            <billTo>
                <firstName>Dustin</firstName>
                <lastName>Chesterman</lastName>
                <company>CFOTools.Net</company>
                <address>123 Main St</address>
                <city>Anytown</city>
                <state>CA</state>
                <zip>12345</zip>
            </billTo>
        </subscription>
    </ARBCreateSubscriptionRequest>
</cfxml>

<cfhttp method="POST" url="https://apitest.authorize.net/xml/v1/request.api" >
    <cfhttpparam type="Header" name="Accept-Encoding" value="deflate;q=0">
    <cfhttpparam type="Header" name="TE" value="deflate;q=0">
    <cfhttpparam name="body" type="xml"
value="#ToString(XMLSubscriptionRequest)#" />
</cfhttp>

<cfdump var="#cfhttp#">
<cfset model = '#ToString(Trim(cfhttp.fileContent))#'>
<cfdump var="#model#">
<br />
<br />
<cfoutput>#ToString(model)#</cfoutput>
<cfset model1 = XmlParse(model)>
<cfdump var="#model1#">

Thanks Paul,  I looked for a BOM after reading another post, but didn't see one
so i didn't even try it :-P  Works perfect now.  Thank you again!

BKBK- I was making sure that i was calling xmlParse in the correct fashion.  
Thanks for you input though.

The REREplaceNoCase line in my code removes the BOM as well, so it may seem
like a duplication, coming after PaulH's code. There was a delay in the post
from the newsgroup. When I composed my last post, PaulH's post of 04/17/2008
06:40:57 AM wasn't yet in the forum.

PaulH wrote:
[i]after reading some W3C stuff on xml & BOMs i'm thinking
that maybe xmlParse() should actually handle this.[/i]

Difficult. BOM is related to unicode, but xmlParse doesn't have any attribute
that relates to encoding.

PaulH,

I am aware of the requirement of an XML parser to be able to determine two
types of information from the BOM or even from the XML declaration. First,
whether the storage type is big-endian or little-endian. Secondly, whether the
document's encoding used 1, 2 or 4 bytes per character. From there, the parser
can get a good idea of the type of encoding.

What made me think it would be difficult is the fact that XMLParse also has
the function of validating XML by means of an external DTD. I can see the point
you make about UTF-16. It would be easy to redesign XMLParse for XML in UTF-16
encoding. As you said, the BOM is a required feature for XML documents in
UTF-16 encoding as well as for their DTDs. However, for most other encodings,
there is no requirement for either BOM or XML declaration in the DTD.