[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HTTPAPI problem with characters in the XML
Hi Scott,
I was able to remove the extra characters from the post. I was using a
variable length field for my WK_XML and didn't realize the first 2
positions were for the length of the field. I changed my post to add 2
to the length of the WK_XML address and was able to remove the
characters.
RC=HTTP_URL_POST(
API_URL1
:%addr(WK_XML) + 2
:%len(%trimr(WK_XML))
:%TRIM(RESP_FILE)
:TIMEOUT
:HTTP_USERAGENT
:'application/PTI68' );
Thanks
Randy Blixt
From: Randy S. Blixt
Sent: Tuesday, July 19, 2016 1:03 PM
To: 'ftpapi@xxxxxxxxxxxxxxxxxxxxxx'
Subject: RE: HTTPAPI problem with characters in the XML
Hi Scott,
The problem is persisting. I looked at my post from UPS and there is
no additional characters before the <?xml version="1.0"
encoding="UTF-8"?>, the only difference in the post is that I am adding
headers to for the credit card Post.
HTTPAPI Ver 1.31 released 2016-02-03
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R1M0
HTTPS_INIT(*BLANKS);
HTTP_XPROC( HTTP_POINT_ADDL_HEADER
: %PADDR(ADD_HEADER) );
RC=HTTP_URL_POST(
API_URL1
:%addr(WK_XML)
:%len(%trimr(WK_XML))
:%TRIM(RESP_FILE)
:TIMEOUT
:HTTP_USERAGENT
:'application/PTI68' );
P ADD_HEADER B
D ADD_HEADER PI
D HEADERS 32767A VARYING
D CRLF C x'0d25'
/FREE
HEADERS =
'MIME-Version: 1.0' + CRLF +
'Content-transfer-encoding: text' + CRLF +
'Request-number: 1' + CRLF +
'Document-type: Request'+ CRLF;
/END-FREE
One thing we noticed was that the XML that fails happens to be 1024 in
the Content-Length, not sure if that has any part of the problem, or if
it's just a coincidence.
We are wondering why there are extra characters added before the XML?
I have an example of a charge that didn't work and the same person who
did work, and the content length was different.
This one didn't work, part of the debug file is below in hex.
55736572 2D416765 6E743A20 68747470 2D617069 User-Agent: http-api
436F6E74 656E742D 54797065 3A206170 706C6963 Content-Type: applic
436F6E74 656E742D 4C656E67 74683A20 31303234 Content-Length: 1024
4D494D45 2D566572 73696F6E 3A20312E 300D0A MIME-Version: 1.0
436F6E74 656E742D 7472616E 73666572 2D656E63 Content-transfer-enc
52657175 6573742D 6E756D62 65723A20 310D0A Request-number: 1
446F6375 6D656E74 2D747970 653A2052 65717565 Document-type: Reque
73656E64 646F6328 293A2065 6E746572 65640D0A senddoc(): entered
9C003C3F 786D6C20 76657273 696F6E3D 22312E30 <?xml version="1.0
3C526571 75657374 3E0D0A <Request>
3C4E6577 4F726465 723E0D0A <NewOrder>
3C4F7262 6974616C 436F6E6E 65637469 6F6E5573 <OrbitalConnectionUs
This was for the same person and it did work.
55736572 2D416765 6E743A20 68747470 2D617069 User-Agent: http-api
436F6E74 656E742D 54797065 3A206170 706C6963 Content-Type: applic
436F6E74 656E742D 4C656E67 74683A20 31303335 Content-Length: 1035
4D494D45 2D566572 73696F6E 3A20312E 300D0A MIME-Version: 1.0
436F6E74 656E742D 7472616E 73666572 2D656E63 Content-transfer-enc
52657175 6573742D 6E756D62 65723A20 310D0A Request-number: 1
446F6375 6D656E74 2D747970 653A2052 65717565 Document-type: Reque
73656E64 646F6328 293A2065 6E746572 65640D0A senddoc(): entered
9C0B3C3F 786D6C20 76657273 696F6E3D 22312E30 <?xml version="1.0
3C526571 75657374 3E0D0A <Request>
3C4E6577 4F726465 723E0D0A <NewOrder>
3C4F7262 6974616C 436F6E6E 65637469 6F6E5573 <OrbitalConnectionUs
From: Randy S. Blixt
Sent: Monday, July 18, 2016 1:51 PM
To: 'ftpapi@xxxxxxxxxxxxxxxxxxxxxx'
Subject: HTTPAPI problem with characters in the XML
Scott,
I am processing credit cards with Chase Paymentech and sending an XML
request. I am getting a few responses from Chase that they are unable
to find the <Request> element of the XML. I have one program creating
the XML request and sporadically I get a bad response. I sent the
problem to Chase Paymentech support and they are unable to give a
definitive answer. Unfortunately I am unable to duplicate the
problem.
The answer I got from Chase is that they did see a special character
between the MIME header and the XML request. I am able to see some
characters between the MIME and the request, but I do not know how they
are getting there.
I posted part of the HTTP_Debug below and you can see just before the
<?xml version="1.0" encoding="UTF-8"?> you can see a character that
should not be there. I start sending at the <?
Do you know why the extra characters are being added? In my testing I
did notice this character changes and it's not always the same.
The actual response from Chase Support.
"We are unable to procure a detailed log on previously run
transactions. Without being able to actively reproduce the issue so we
may get a live log on our end; the issue will be hard to pinpoint. What
we can tell is your MIME header came in just fine on those error
transactions. We also logged a few recent transactions and noticed that
between the MIME header and the actual transaction request there was an
invalid character of "¬". For example: ¬<?xml version="1.0"
encoding="UTF-8"?> <Request>. If this character was injected at any
point within the start of the xml tag it could cause the <Request> tag
to not be found. Our recommendation would be to review your code to see
why it might be sending that character, or if in certain instances it
might be injecting any other unsupported characters into the request."
Protocol Used: TLS Version 1.2
http_persist_post(): entered
http_persist_req(POST) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(POST): entered
There are 0 cookies in the cache
POST /authorize HTTP/1.1
Host: orbitalvar1.chasepaymentech.com
User-Agent: http-api/1.31
Content-Type: application/PTI68
Content-Length: 976
MIME-Version: 1.0
Content-transfer-encoding: text
Request-number: 1
Document-type: Request
senddoc(): entered
_______________________
}<?xml version="1.0" encoding="UTF-8"?>
<Request>
<NewOrder>
The paste looks different from the actual debug file so I added the
picture.
[cid:image001.png@01D1E1CD.8243C600]
Thanks,
Randy
CONFIDENTIALITY NOTICE: This electronic message transmission contains
information from this organization, which may be confidential or
privileged. The information is intended for the sole use of the
individual or entity named above. If you are not the intended
recipient, be aware that any disclosure, copying, distribution, or use
of the contents of this information is prohibited. If you have received
this email in error, please notify the sender immediately and delete
the original message. Neither the sender nor the company for which he
or she works accepts any liability for any damage caused by any virus
transmitted by this email.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------