[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ftpapi Digest, Vol 60, Issue 11
Hi Jim,
Please, please, please do not use Digest mode for the list. Please
Please please please... it's very disruptive.
If you MUST use digest mode despite my plea, then you need to do the
following:
1) Change the subject of the message to match the subject of the one
you're replying to. In this case, the subject should be "Re: HTTP/1.1
412 Precondition Failed" it should NOT be "Ftpapi Digest, Vol 60".
2) Remove all unnecessary material from the message. Don't make me hunt
through all of the messages in that issue of the digest to figure out
what you're replying to. Remove everything except the few phrases that
you're directly responding to.
But you can make this all much simpler by turning the (horrible) digest
mode off. Honestly, I tried to hide the Digest option from list
subscribers... I guess I didn't do a very good job.
Doing this will save me a lot of time when I try to help you -- and
that's *crucial*, because I'm only one man, and have thousands of people
asking me for help. Time is of the essence.
Thanks
On 6/8/2011 9:33 AM, Jim Ward wrote:
>
> Thanks for the info, here is further information:
> Security information is send in the SOAP Body. You can see it below
> in the debugs at the tag:<ns1:orbitalConnectionUsername> and
> <ns1:orbitalConnectionPassword>. I have ***ed out the Password, but
> it really is being sent - same in both cases
> We are not creating custom headers. I read the historical post and
> that describes the problem. We originally wanted to do XML direac
> with them but they required a MIME header which we could not generate
> and they were unable to rell me what they were looking for. They said
> SOAP did not require a MIME header. I do note in the reply they sent
> that the CRLF seemed to be missing - there is a ";" where I would
> expect it:
> Host: wsvar2.paymentech.net; User-Agent: http-api/1.23; Content-Type:
> text/xml; Expect: 100-continue; Content-Length: 1105;
> Yes, the program makes two different posts to Orbital gateway. It
> runs a screen that allows a user to do an "Authorize" post (which
> works fine) and a "Profile Add" which does not work. The program uses
> the same Soap Env header for each transaction type, only the Soap Body
> is different.
> I have attached two complete debugs from the http_url_post_xml call -
> I don't know any way of getting more detail other than setting the
> debug on: callp http_debug(*ON) .
> The debugs are rather lengthy - sorry.
> Jim Ward
> Here is the Debug from the good transaction:
> HTTPAPI Ver 1.23 released 2008-04-24
> OS/400 Ver V5R4M0
> New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819.
> ProtLoc=0
> http_persist_open(): entered
> http_long_ParseURL(): entered
> DNS resolver retrans: 2
> DNS resolver retry : 2
> DNS resolver options: x'00000136'
> DNS default domain: hq.mdi
> DNS server found: 172.16.3.209
> DNS server found: 172.16.3.208
> https_init(): entered
> ----------------------------------------------------------------------
> ---------------
> Dump of local-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> -----BEGIN CERTIFICATE-----
> MIICiTCCAfKgAwIBAgIHP87w9g8EeDANBgkqhkiG9w0BAQQFADCBijELMAkGA1UE
> BhMCVVMxETAPBgNVBAgTCE1pY2hpZ2FuMRkwFwYDVQQHExBGYXJtaW5ndG9uIEhp
> bGxzMSkwJwYDVQQKEyBNYXJrZXRpbmcgRGlzcGxheXMgSW50ZXJuYXRpb25hbDEi
> MCAGA1UEAxMZQ2xpZW50IEFjY2VzcyBDZXJ0aWZpY2F0ZTAeFw0wMzEyMDMwODMx
> NTFaFw0wOTA1MjYwODMxNTFaMIGDMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWlj
> aGlnYW4xGTAXBgNVBAcTEEZhcm1pbmd0b24gSGlsbHMxKTAnBgNVBAoTIE1hcmtl
> dGluZyBEc2lwbGF5cyBJbnRlcm5hdGlvbmFsMRswGQYDVQQDExJDQSBTU0wgQ2Vy
> dGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKz+Z8JIEW6P/Z5Y
> X8G+8nhYCh3zlIIBa2ip/ghw2ez+zFLOrFk9sC1vppocj9BQzLo1qJ4NZ+ej6hEh
> 79WV+FiRKEI8YWt5IT0B3Pa+1lKhK6xdBS9LBDupFJ5a3Q+KL8KDFXCVvNKvEGKV
> w9c7fPYqrsd467/GSrQ4DlbOTbP1AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAY5VO
> rkOyl84Gj3kNzwfhD4XSih/JYdVEnvsaBMN8SkVZZvmmULsGNqyV1bMBMvJklvyM
> 8pMK/qkpUOzEIk17B1jX44tkcbYlLXFQE90ZkxSgbQu3pvOG0DEHDSCSRj+vHvA1
> iPvpHuQbuJeop8HTclGOcKoulTUfOQXLvTzdeX4=
> -----END CERTIFICATE-----
> Serial Number: 3F:CE:F0:F6:0F:04:78
> Common Name: CA SSL Certificate
> Country: US
> State/Province: Michigan
> Locality: Farmington Hills
> Org Unit: Marketing Dsiplays International
> Issuer CN: Client Access Certificate
> Issuer Country: US
> Issuer State/Province: Michigan
> Issuer Locality: Farmington Hills
> Issuer Org: Marketing Displays International
> Version: 03
> not before: 20031203043151
> not after: 20090526043151
> pub key alg: 1.2.840.113549.1.1.4
> ----------------------------------------------------------------------
> ---------------
> Dump of server-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> Cert Validation Code = 0
> -----BEGIN CERTIFICATE-----
> MIIFlzCCBH+gAwIBAgIQF4sLqfIdY68+cuaiUKzqnzANBgkqhkiG9w0BAQUFADCB
> vDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMt
> VmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4X
> DTEwMTIyOTAwMDAwMFoXDTExMTIyOTIzNTk1OVowgZoxCzAJBgNVBAYTAlVTMRAw
> DgYDVQQIEwdGbG9yaWRhMQ4wDAYDVQQHFAVUYW1wYTEjMCEGA1UEChQaQ2hhc2Ug
> UGF5bWVudGVjaCBTb2x1dGlvbnMxJDAiBgNVBAsUG0VudGVycHJpc2UgV2ViIEFy
> Y2hpdGVjdHVyZTEeMBwGA1UEAxQVd3N2YXIyLnBheW1lbnRlY2gubmV0MIIBIjAN
> BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvNhPGcbm7ynYD/+T8wXZ05nFOgGz
> 470rk5wSGUZHfjfxZ0/RtLVo+WMb2Q7FC2wf5kryA0PZtp19fmMbn2TpFp/VNpe9
> l5nYAoDK0X1KPHKeqoSqG6FWnECJkrLHCj4kbZz96yzXZMgzrRgaeo96eOlreUug
> Hqc87vvM0T9la2VKP1IT0JeqwXD0Li7YhDGHJ7uxhKsu0rREqBe+1wxlUZON3PRr
> 6HG+khZro8IyJoiRq5dr/7FO95yqEQi/Aur4hvrX31B0MZrvvAza6UC/KHQuucl2
> bhHjCq0JSEWXVnimEmOebavgJKwxpg6PBs05SvE/EdycCe51HB1Pd19NFwIDAQAB
> o4IBszCCAa8wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwQQYDVR0fBDowODA2oDSg
> MoYwaHR0cDovL1NWUkludGwtRzMtY3JsLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMu
> Y3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0
> cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAoBgNVHSUEITAfBglghkgBhvhCBAEG
> CCsGAQUFBwMBBggrBgEFBQcDAjByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGG
> GGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NW
> UkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMG4GCCsGAQUF
> BwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiW
> Bgy70FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xv
> Z28xLmdpZjANBgkqhkiG9w0BAQUFAAOCAQEAJJEERjh42QlAvQk6vtuwQ+0/p/gN
> PvmFuyyDA4piXxQ55mK96hRNJrCjgv3dSieXUP2QSQKDlQah0XgNQ5nAdvQKm9ME
> foNxhEuU9szvYrk6eWY6TaJOT0+/9GGHjYiBqJmJvHdWjInlgIC4KbYr+JrPZ2Ny
> xM2EdSX2bF1wWmVPhRG43O4ncVSBL/+CH5tHd06SHj2kU3upzrbyfZlBWVxLuEiD
> 8lQZP9NRYmB2QEeXedHrIVaoIl/IjBYOM4/maYKcka4ic/ZDkIaKrd+tOrYJZR78
> 9NpwBwUqV1TZFxrwRQTOh5WW7SoUUnvm/ZLn1EmqP3oYh2xdJux4Wf0/RQ==
> -----END CERTIFICATE-----
> Serial Number: 17:8B:0B:A9:F2:1D:63:AF:3E:72:E6:A2:50:AC:EA:9F
> Common Name: wsvar2.paymentech.net
> Country: US
> State/Province: Florida
> Locality: Tampa
> Org Unit: Chase Paymentech Solutions
> Org: Enterprise Web Architecture
> Issuer CN: VeriSign Class 3 International Server CA - G3
> Issuer Country: US
> Issuer Org: VeriSign, Inc.
> Issuer Org Unit: Terms of use at https://www.verisign.com/rpa (c)10,
> OU=VeriSign Trust Network
> Version: 03
> not before: 20101228200000
> not after: 20111229195959
> pub key alg: 1.2.840.113549.1.1.5
> Protocol Used: TLS Version 1
> http_persist_post(): entered
> http_long_ParseURL(): entered
> do_post(): entered
> POST /PaymentechGateway HTTP/1.1
> Host: wsvar2.paymentech.net
> User-Agent: http-api/1.23
> Content-Type: text/xml
> Expect: 100-continue
> Content-Length: 964
> recvresp(): entered
> HTTP/1.1 100 Continue
> SetError() #13: HTTP/1.1 100 Continue
> senddoc(): entered
> <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soapenv:Body><N
> ewOrder
> xmlns="urn:ws.paymentech.net/PaymentechGateway"><newOrderRequest
> xsi:type="ns1:NewOrderRequestElement"
> xmlns:ns1="urn:ws.paymentech.net/PaymentechGateway"
> xmlns=""><ns1:orbitalConnectionUsername>MD1W0RLD</ns1:orbitalConnectio
> nUsername><ns1:orbitalConnectionPassword>*******</ns1:orbitalConnectio
> nPassword><ns1:version>2.2</ns1:version><ns1:industryType>EC</ns1:indu
> stryType><ns1:transType>A</ns1:transType><ns1:bin>000002</ns1:bin><ns1
> :merchantID>700000003908</ns1:merchantID><ns1:terminalID>001</ns1:term
> inalID><ns1:ccAccountNum>5555555555554444</ns1:ccAccountNum><ns1:ccExp
> >201212</ns1:ccExp><ns1:orderID>96773000</ns1:orderID><ns1:amount>0013
> 41600</ns1:amount></newOrderRequest></NewOrder></soapenv:Body></soapen
> v:Envelope>
> recvresp(): entered
> HTTP/1.1 200 OK
> Date: Wed, 08 Jun 2011 12:50:04 GMT
> Server: gSOAP/2.6
> Content-Type: text/xml; charset=utf-8
> Content-Length: 2213
> X-Cnection: close
> Connection: close
> SetError() #13: HTTP/1.1 200 OK
> recvdoc parms: identity 2213
> header_load_cookies() entered
> recvdoc(): entered
> SetError() #0:
> <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="urn:ws.paymentech.net/PaymentechGateway"><SOAP-ENV:Body
> id="_0"><NewOrderResponse
> xmlns="urn:ws.paymentech.net/PaymentechGateway"
> xsi:type="ns:NewOrderResponse"><return
> xsi:type="ns:NewOrderResponseElement"><industryType
> xsi:type="xsd:string">EC</industryType><transType
> xsi:type="xsd:string">A</transType><bin
> xsi:type="xsd:string">000002</bin><merchantID
> xsi:type="xsd:string">700000003908</merchantID><terminalID
> xsi:type="xsd:string">001</terminalID><cardBrand
> xsi:type="xsd:string">MC</cardBrand><orderID
> xsi:type="xsd:string">96773000</orderID><txRefNum
> xsi:type="xsd:string">4DEF6FFEA323F91D8E655286C9AF892D41EE5401</txRefN
> um><txRefIdx xsi:type="xsd:string">0</txRefIdx><respDateTime
> xsi:type="xsd:string">20110608085006</respDateTime><procStatus
> xsi:type="xsd:string">0</procStatus><approvalStatus
> xsi:type="xsd:string">1</approvalStatus><respCode
> xsi:type="xsd:string">00</respCode><avsRespCode xsi:type="xsd:string">
> </avsRespCode><cvvRespCode xsi:type="xsd:string">
> </cvvRespCode><authorizationCode
> xsi:type="xsd:string">194616</authorizationCode><mcRecurringAdvCode
> xsi:type="xsd:string"></mcRecurringAdvCode><visaVbVRespCode
> xsi:type="xsd:string"></visaVbVRespCode><procStatusMessage
> xsi:type="xsd:string">Approved</procStatusMessage><respCodeMessage
> xsi:type="xsd:string"></respCodeMessage><hostRespCode
> xsi:type="xsd:string">00</hostRespCode><hostAVSRespCode
> xsi:type="xsd:string"></hostAVSRespCode><hostCVVRespCode
> xsi:type="xsd:string"></hostCVVRespCode><retryTrace
> xsi:type="xsd:string"></retryTrace><retryAttempCount
> xsi:type="xsd:string"></retryAttempCount><lastRetryDate
> xsi:type="xsd:string"></lastRetryDate><customerRefNum
> xsi:type="xsd:string"></customerRefNum><customerName
> xsi:type="xsd:string"></customerName><profileProcStatus
> xsi:type="xsd:string"></profileProcStatus><profileProcStatusMsg
> xsi:type="xsd:string"></profileProcStatusMsg></return></NewOrderRespon
> se></SOAP-ENV:Body></SOAP-ENV:Envelope>
> http_close(): entered
> Here is the debug from the bad transaction:
> HTTPAPI Ver 1.23 released 2008-04-24
> OS/400 Ver V5R4M0
> New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819.
> ProtLoc=0
> http_persist_open(): entered
> http_long_ParseURL(): entered
> DNS resolver retrans: 2
> DNS resolver retry : 2
> DNS resolver options: x'00000136'
> DNS default domain: hq.mdi
> DNS server found: 172.16.3.209
> DNS server found: 172.16.3.208
> https_init(): entered
> ----------------------------------------------------------------------
> ---------------
> Dump of local-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> -----BEGIN CERTIFICATE-----
> MIICiTCCAfKgAwIBAgIHP87w9g8EeDANBgkqhkiG9w0BAQQFADCBijELMAkGA1UE
> BhMCVVMxETAPBgNVBAgTCE1pY2hpZ2FuMRkwFwYDVQQHExBGYXJtaW5ndG9uIEhp
> bGxzMSkwJwYDVQQKEyBNYXJrZXRpbmcgRGlzcGxheXMgSW50ZXJuYXRpb25hbDEi
> MCAGA1UEAxMZQ2xpZW50IEFjY2VzcyBDZXJ0aWZpY2F0ZTAeFw0wMzEyMDMwODMx
> NTFaFw0wOTA1MjYwODMxNTFaMIGDMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWlj
> aGlnYW4xGTAXBgNVBAcTEEZhcm1pbmd0b24gSGlsbHMxKTAnBgNVBAoTIE1hcmtl
> dGluZyBEc2lwbGF5cyBJbnRlcm5hdGlvbmFsMRswGQYDVQQDExJDQSBTU0wgQ2Vy
> dGlmaWNhdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKz+Z8JIEW6P/Z5Y
> X8G+8nhYCh3zlIIBa2ip/ghw2ez+zFLOrFk9sC1vppocj9BQzLo1qJ4NZ+ej6hEh
> 79WV+FiRKEI8YWt5IT0B3Pa+1lKhK6xdBS9LBDupFJ5a3Q+KL8KDFXCVvNKvEGKV
> w9c7fPYqrsd467/GSrQ4DlbOTbP1AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAY5VO
> rkOyl84Gj3kNzwfhD4XSih/JYdVEnvsaBMN8SkVZZvmmULsGNqyV1bMBMvJklvyM
> 8pMK/qkpUOzEIk17B1jX44tkcbYlLXFQE90ZkxSgbQu3pvOG0DEHDSCSRj+vHvA1
> iPvpHuQbuJeop8HTclGOcKoulTUfOQXLvTzdeX4=
> -----END CERTIFICATE-----
> Serial Number: 3F:CE:F0:F6:0F:04:78
> Common Name: CA SSL Certificate
> Country: US
> State/Province: Michigan
> Locality: Farmington Hills
> Org Unit: Marketing Dsiplays International
> Issuer CN: Client Access Certificate
> Issuer Country: US
> Issuer State/Province: Michigan
> Issuer Locality: Farmington Hills
> Issuer Org: Marketing Displays International
> Version: 03
> not before: 20031203043151
> not after: 20090526043151
> pub key alg: 1.2.840.113549.1.1.4
> ----------------------------------------------------------------------
> ---------------
> Dump of server-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> Cert Validation Code = 0
> -----BEGIN CERTIFICATE-----
> MIIFlzCCBH+gAwIBAgIQF4sLqfIdY68+cuaiUKzqnzANBgkqhkiG9w0BAQUFADCB
> vDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMt
> VmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4X
> DTEwMTIyOTAwMDAwMFoXDTExMTIyOTIzNTk1OVowgZoxCzAJBgNVBAYTAlVTMRAw
> DgYDVQQIEwdGbG9yaWRhMQ4wDAYDVQQHFAVUYW1wYTEjMCEGA1UEChQaQ2hhc2Ug
> UGF5bWVudGVjaCBTb2x1dGlvbnMxJDAiBgNVBAsUG0VudGVycHJpc2UgV2ViIEFy
> Y2hpdGVjdHVyZTEeMBwGA1UEAxQVd3N2YXIyLnBheW1lbnRlY2gubmV0MIIBIjAN
> BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvNhPGcbm7ynYD/+T8wXZ05nFOgGz
> 470rk5wSGUZHfjfxZ0/RtLVo+WMb2Q7FC2wf5kryA0PZtp19fmMbn2TpFp/VNpe9
> l5nYAoDK0X1KPHKeqoSqG6FWnECJkrLHCj4kbZz96yzXZMgzrRgaeo96eOlreUug
> Hqc87vvM0T9la2VKP1IT0JeqwXD0Li7YhDGHJ7uxhKsu0rREqBe+1wxlUZON3PRr
> 6HG+khZro8IyJoiRq5dr/7FO95yqEQi/Aur4hvrX31B0MZrvvAza6UC/KHQuucl2
> bhHjCq0JSEWXVnimEmOebavgJKwxpg6PBs05SvE/EdycCe51HB1Pd19NFwIDAQAB
> o4IBszCCAa8wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwQQYDVR0fBDowODA2oDSg
> MoYwaHR0cDovL1NWUkludGwtRzMtY3JsLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMu
> Y3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0
> cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAoBgNVHSUEITAfBglghkgBhvhCBAEG
> CCsGAQUFBwMBBggrBgEFBQcDAjByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGG
> GGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NW
> UkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMG4GCCsGAQUF
> BwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiW
> Bgy70FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xv
> Z28xLmdpZjANBgkqhkiG9w0BAQUFAAOCAQEAJJEERjh42QlAvQk6vtuwQ+0/p/gN
> PvmFuyyDA4piXxQ55mK96hRNJrCjgv3dSieXUP2QSQKDlQah0XgNQ5nAdvQKm9ME
> foNxhEuU9szvYrk6eWY6TaJOT0+/9GGHjYiBqJmJvHdWjInlgIC4KbYr+JrPZ2Ny
> xM2EdSX2bF1wWmVPhRG43O4ncVSBL/+CH5tHd06SHj2kU3upzrbyfZlBWVxLuEiD
> 8lQZP9NRYmB2QEeXedHrIVaoIl/IjBYOM4/maYKcka4ic/ZDkIaKrd+tOrYJZR78
> 9NpwBwUqV1TZFxrwRQTOh5WW7SoUUnvm/ZLn1EmqP3oYh2xdJux4Wf0/RQ==
> -----END CERTIFICATE-----
> Serial Number: 17:8B:0B:A9:F2:1D:63:AF:3E:72:E6:A2:50:AC:EA:9F
> Common Name: wsvar2.paymentech.net
> Country: US
> State/Province: Florida
> Locality: Tampa
> Org Unit: Chase Paymentech Solutions
> Org: Enterprise Web Architecture
> Issuer CN: VeriSign Class 3 International Server CA - G3
> Issuer Country: US
> Issuer Org: VeriSign, Inc.
> Issuer Org Unit: Terms of use at https://www.verisign.com/rpa (c)10,
> OU=VeriSign Trust Network
> Version: 03
> not before: 20101228200000
> not after: 20111229195959
> pub key alg: 1.2.840.113549.1.1.5
> Protocol Used: TLS Version 1
> http_persist_post(): entered
> http_long_ParseURL(): entered
> do_post(): entered
> POST /PaymentechGateway HTTP/1.1
> Host: wsvar2.paymentech.net
> User-Agent: http-api/1.23
> Content-Type: text/xml
> Expect: 100-continue
> Content-Length: 1450
> recvresp(): entered
> HTTP/1.1 100 Continue
> SetError() #13: HTTP/1.1 100 Continue
> senddoc(): entered
> <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soapenv:Body><P
> rofileAdd
> xmlns="urn:ws.paymentech.net/PaymentechGateway"><profileAddRequest
> xsi:type="ns1:profileAddRequest"
> xmlns:ns1="urn:ws.paymentech.net/PaymentechGateway"
> xmlns=""><ns1:orbitalConnectionUsername>MD1W0RLD</ns1:orbitalConnectio
> nUsername><ns1:orbitalConnectionPassword>********</ns1:orbitalConnecti
> onPassword><ns1:version>2.2</ns1:version><ns1:bin>000002</ns1:bin><ns1
> :merchantID>700000003908</ns1:merchantID><ns1:customerName>ASDFASDFASF
> </ns1:customerName><ns1:customerAddress1>ASDFASDFASDF</ns1:customerAdd
> ress1><ns1:customerAddress2>ASDFASDFASDF/<ns1:customerAddress2><ns1:cu
> stomerCity>ASDFASDFASD</ns1:customerCity><ns1:customerState>ST</ns1:cu
> stomerState><ns1:customerZIP>12345</ns1:customerZIP><ns1:customerCount
> ryCode>US</ns1:customerCountryCode><ns1:customerProfileOrderOverideInd
> >NO</ns1:customerProfileOrderOverideInd><ns1:customerProfileFromOrderI
> nd>A</ns1:customerProfileFromOrderInd><ns1:orderID>76773000</ns1:order
> ID><ns1:orderDefaultAmount>000013520</ns1:orderDefaultAmount><ns1:cust
> omerAccountType>CC</ns1:customerAccountType><ns1:ccAccountNum>40128888
> 88881881</ns1:ccAccountNum><ns1:ccExp>201212</ns1:ccExp><ns1:status>A<
> /ns1:status></profileAddRequest></ProfileAdd></soapenv:Body></soapenv:
> Envelope>
> recvresp(): entered
> HTTP/1.1 412 Precondition Failed
> Date: Wed, 08 Jun 2011 13:32:04 GMT
> Content-Length: 541
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
> SetError() #13: HTTP/1.1 412 Precondition Failed
> recvdoc parms: identity 541
> header_load_cookies() entered
> recvdoc(): entered
> SetError() #0:
> <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="urn:ws.paymentech.net/PaymentechGateway"><SOAP-ENV:Body
> id="_0"><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultst
> ring>20412: Precondition Failed: Security Information is
> missing</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envel
> ope>
> SetError() #13: HTTP/1.1 412 Precondition Failed
> http_close(): entered
>
> ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
> Sent by: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>
> 06/08/2011 05:23 AM
>
> Please respond to
> ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>
> To
>
> ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>
> cc
>
> Subject
>
> Ftpapi Digest, Vol 60, Issue 11
>
> Send Ftpapi mailing list submissions to
> ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.scottklement.com/mailman/listinfo/ftpapi
> or, via email, send a message with subject or body 'help' to
> ftpapi-request@xxxxxxxxxxxxxxxxxxxxxx
> You can reach the person managing the list at
> ftpapi-owner@xxxxxxxxxxxxxxxxxxxxxx
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ftpapi digest..."
> Today's Topics:
> 1. Re: The length requested for storage allocation is out of
> range (Scott Klement)
> 2. HTTP/1.1 412 Precondition Failed (Jim Ward)
> 3. Re: HTTP/1.1 412 Precondition Failed (Michael Ryan)
> 4. RE: HTTP/1.1 412 Precondition Failed (Mike Krebs)
> 5. Base64 (Bing@xxxxxxxxxx)
> 6. Re: Base64 (Scott Klement)
> 7. R: Base64 (Luciano Vigna)
> ----------------------------------------------------------------------
> Message: 1
> Date: Tue, 07 Jun 2011 12:04:41 -0500
> From: Scott Klement<sk@xxxxxxxxxxxxxxxx>
> Subject: Re: The length requested for storage allocation is out of
> range
> To: HTTPAPI and FTPAPI Projects<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:<4DEE5A29.7060103@xxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> hi Kim,
> > The error is occurring in http_url_post_xml. Here's the statement
> that
> > I'm using - cTimeOut is set at 600. Could that be the problem
> I don't see how a timeout could cause a problem with storage
> allocation?!
> > - I'm not giving enough time to receive the entire response? The
> > response of this web service can be pretty slow.
> The timeout isn't the total download time, it's the amount of "lull"
> that can occur.
> HTTPAPI is sitting in a loop, reading bytes off of the network, and
> (in
> your case) handing them to the XML parser. As long as it continues to
> receive data, it's happy. It doesn't matter how slowly that data
> appears, as long as it receives a byte every so often, it's happy.
> In your case, if no bytes at all are received for 10 minutes, it'll
> signal a timeout. To me, that's an absurdly long timeout. Even in
> dialup days, we typically got transfer rates of at least 33.6k/sec --
> 33600 bits per second, or approx 4000 bytes/sec.
> You have your timeout to allow 1 byte per 10 minutes.
> I guess if you have to wait 10 minutes for the program to process on
> the
> remote end (maybe it's running a long SQL query, during which nothing
> is
> sent) your timeout makes sense... but I just can't see how it could
> possibly affect storage allocation.
> > The first time this error occurred the content-length was 10833517,
> and
> > only 9846465 was received. The second time it happened the
> > content-length was 10164047, and 9857785 was received (I isolated
> the
> > response portion of each debug file into a text file to determine
> the
> > size of the response received).
> Unless it's receiving the whole document in a single lump, I don't see
> why the content-length would matter.
> If you want to debug this yourself, I suggest this strategy:
> 1) When it blows up, find the precise statement of HTTPAPI that it
> blows
> up on.
> 2) Find out the size of the storage it's allocating. Is it larger
> than
> 16mb? If so, why is HTTPAPI asking for so much? Or is it less than
> 0,
> in which case there's a more severe error.
> 3) Trade the code back, and find out how it calculated the storage
> size.
> Is there anything it could've done better?
> > I'm only keeping a week's worth of debug logs, but the next largest
> > content-length I've received was 5921033, and it was received in its
> > entirety without a problem. So I guess I'm assuming it's erroring
> out
> > whenever I receive a response of a certain size.
> AFAIK, HTTPAPI itself doesn't care about the size of the total
> response.
> However, the XML parsing routines, will need to allocate enough memory
> for the contents of a whole XML element -- this is where you're more
> likely to have a problem.
> > As for reproducing the problem - I suppose I could send you the
> response
> > that I have in the debug file with the identifying information
> removed,
> > and I can doctor it up so that it is the correct content? Would that
> > help?
> If HTTPAPI is crashing, I doubt you're getting the whole response in
> the
> debug file.
> What you could do, however, is use http_url_post() (instead of
> post_xml)
> so that HTTPAPI saves the response to disk. Does that produce the
> same
> error? If not, try parsing the XML document with
> http_parse_xml_stmf().
> Does that produce the same error? I'm guessing it would.
> Then send me the XML file.... then I can use it to reproduce the
> problem, and figure out how to work around it in the code.
> ------------------------------
> Message: 2
> Date: Tue, 7 Jun 2011 15:22:49 -0400
> From: "Jim Ward"<JWard@xxxxxxxxxxxxxxxx>
> Subject: HTTP/1.1 412 Precondition Failed
> To: "ftpapi"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:
>
> <OF2BF4839C.E9768C5C-ON852578A8.0068AFB2-852578A8.006A7686@LocalDomain
> >
>
> Content-Type: text/plain; charset="us-ascii"
> We are new users of HTTPAPI. I am posting a SOAP message to Chase
> Orbitaal Gateway.
> Here is the code I am using to post (copied from one of the examples):
> rc =
> http_url_post_xml('https://wsvar2.paymentech.net/PaymentechGateway'
> : %addr(postData) + 2
> : %len(postData)
> : %paddr(StartOfElement)
> : %paddr(EndOfElement)
> : *NULL );
> It fails with the following debug:
> SetError() #13: HTTP/1.1 412 Precondition Failed
> recvdoc parms: identity 541
> header_load_cookies() entered
> recvdoc(): entered
> SetError() #0:
> <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="urn:ws.paymentech.net/PaymentechGateway"><SOAP-ENV:Body
> id="_0"><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultst
> ring>20412:
> Precondition Failed: Security Information is
> missing</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envel
> ope>
> SetError() #13: HTTP/1.1 412 Precondition Failed
> http_close(): entered
> Orbital gateway says this is what they are receiving on their server:
> Failed 20412:
> Host: wsvar2.paymentech.net; User-Agent: http-api/1.23; Content-Type:
> text/xml; Expect: 100-continue; Content-Length: 1105;
> Instead of this (from other successful posts in the program using the
> same
> call above)
> Successful:
> POST /PaymentechGateway HTTP/1.1
> Host: 172.21.55.254:8083
> User-Agent: http-api/1.23
> Content-Type: text/xml
> Expect: 100-continue
> auth-mid: 700000003908
> auth-tid: 001
> auth-user: MD1W0RLD
> x-forwarded-txid: tHWEyQoBAGwAAGbeY48AAAAX
> Max-Forwards: 10
> X-Forwarded-For: 24.172.191.146
> X-Forwarded-Host: wsvar2.paymentech.net
> X-Forwarded-Server: wsvar2.paymentech.net
> Connection: Keep-Alive
> Content-Length: 964
> Anyone have any ideas what I should try?
> P before printing this message, please consider our environment
> CONFIDENTIALITY NOTICE This e-mail message, including any
> attachments, is for the sole use of the intended recipients(s) and may
> contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
> -------------- next part --------------
> We are new users of HTTPAPI. I am posting a SOAP message to Chase
> Orbitaal Gateway.
> Here is the code I am using to post (copied from one of the
> examples):
> rc =
> http_url_post_xml('https://wsvar2.paymentech.net/PaymentechGateway'
> : %addr(postData) + 2
> : %len(postData)
> : %paddr(StartOfElement)
> : %paddr(EndOfElement)
> : *NULL );
> It fails with the following debug:
> SetError() #13: HTTP/1.1 412 Precondition Failed
> recvdoc parms: identity 541
> header_load_cookies() entered
> recvdoc(): entered
> SetError() #0:
> <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:ns="urn:ws.paymentech.net/PaymentechGateway"><SOAP-ENV:Body
>
> id="_0"><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultst
> ring>20412: Precondition Failed: Security Information is
>
> missing</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envel
> ope>
> SetError() #13: HTTP/1.1 412 Precondition Failed
> http_close(): entered
> Orbital gateway says this is what they are receiving on their
> server:
> Failed 20412:
> Host: wsvar2.paymentech.net; User-Agent: http-api/1.23;
> Content-Type:
> text/xml; Expect: 100-continue; Content-Length: 1105;
> Instead of this (from other successful posts in the program using
> the
> same call above)
> Successful:
> POST /PaymentechGateway HTTP/1.1
> Host: 172.21.55.254:8083
> User-Agent: http-api/1.23
> Content-Type: text/xml
> Expect: 100-continue
> auth-mid: 700000003908
> auth-tid: 001
> auth-user: MD1W0RLD
> x-forwarded-txid: tHWEyQoBAGwAAGbeY48AAAAX
> Max-Forwards: 10
> X-Forwarded-For: 24.172.191.146
> X-Forwarded-Host: wsvar2.paymentech.net
> X-Forwarded-Server: wsvar2.paymentech.net
> Connection: Keep-Alive
> Content-Length: 964
> Anyone have any ideas what I should try?
> _________________________________________________________________
> P before printing this message, please consider our environment
> CONFIDENTIALITY NOTICE
> This e-mail message, including any attachments, is for the sole use
> of
> the intended recipients(s) and may contain confidential and
> privileged
> information. Any unauthorized review, use, disclosure or
> distribution
> is prohibited. If you are not the intended recipient, please contact
> the sender by reply e-mail and destroy all copies of the original
> message.
> ------------------------------
> Message: 3
> Date: Tue, 7 Jun 2011 16:03:34 -0400
> From: Michael Ryan<michaelrtr@xxxxxxxxx>
> Subject: Re: HTTP/1.1 412 Precondition Failed
> To: HTTPAPI and FTPAPI Projects<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:<BANLkTi=5kXEcNGHPajpPuVn23fApu4qb=Q@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
> Looks like security information is missing:
> <faultstring>20412: Precondition Failed: Security Information is
> missing</faultstring>
> Are you specifying the security information?
> On Tue, Jun 7, 2011 at 3:22 PM, Jim Ward<JWard@xxxxxxxxxxxxxxxx>
> wrote:
> >
> > ? We are new users of HTTPAPI. ?I am posting a SOAP message to Chase
> > ? Orbitaal Gateway.
> > ? Here is the code I am using to post (copied from one of the
> examples):
> > ? rc =
> > ?
> http_url_post_xml('https://wsvar2.paymentech.net/PaymentechGateway'
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : %addr(postData) + 2
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : %len(postData)
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : %paddr(StartOfElement)
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : %paddr(EndOfElement)
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : *NULL );
> > ? It fails with the following debug:
> > ? SetError() #13: HTTP/1.1 412 Precondition Failed
> > ? recvdoc parms: identity 541
> > ? header_load_cookies() entered
> > ? recvdoc(): entered
> > ? SetError() #0:
> > ?<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
> > ? xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> > ? xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> > ? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > ? xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > ? xmlns:ns="urn:ws.paymentech.net/PaymentechGateway"><SOAP-ENV:Body
> > ?
> id="_0"><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultst
> > ? ring>20412: Precondition Failed: Security Information is
> > ?
> missing</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envel
> > ? ope>
> > ? SetError() #13: HTTP/1.1 412 Precondition Failed
> > ? http_close(): entered
> > ? Orbital gateway says this is what they are receiving on their
> server:
> > ? Failed 20412:
> > ? Host: wsvar2.paymentech.net; User-Agent: http-api/1.23;
> Content-Type:
> > ? text/xml; Expect: 100-continue; Content-Length: 1105;
> > ? Instead of this (from other successful posts in the program using
> the
> > ? same call above)
> > ? Successful:
> > ? POST /PaymentechGateway HTTP/1.1
> > ? Host: 172.21.55.254:8083
> > ? User-Agent: http-api/1.23
> > ? Content-Type: text/xml
> > ? Expect: 100-continue
> > ? auth-mid: 700000003908
> > ? auth-tid: 001
> > ? auth-user: MD1W0RLD
> > ? x-forwarded-txid: tHWEyQoBAGwAAGbeY48AAAAX
> > ? Max-Forwards: 10
> > ? X-Forwarded-For: 24.172.191.146
> > ? X-Forwarded-Host: wsvar2.paymentech.net
> > ? X-Forwarded-Server: wsvar2.paymentech.net
> > ? Connection: Keep-Alive
> > ? Content-Length: 964
> > ? Anyone have any ideas what I should try?
> > ? ?
> _________________________________________________________________
> >
> > ? P before printing this message, please consider our environment
> > ? CONFIDENTIALITY NOTICE
> >
> > ? This e-mail message, including any attachments, is for the sole
> use of
> > ? the intended recipients(s) and may contain confidential and
> privileged
> > ? information. Any unauthorized review, use, disclosure or
> distribution
> > ? is prohibited. If you are not the intended recipient, please
> contact
> > ? the sender by reply e-mail and destroy all copies of the original
> > ? message.
> >
> >
> ----------------------------------------------------------------------
> -
> > This is the FTPAPI mailing list. ?To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> >
> ----------------------------------------------------------------------
> -
> >
> >
> ------------------------------
> Message: 4
> Date: Tue, 7 Jun 2011 16:37:18 -0500
> From: Mike Krebs<mkrebs@xxxxxxxxxxxxxxxxxx>
> Subject: RE: HTTP/1.1 412 Precondition Failed
> To: HTTPAPI and FTPAPI Projects<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:<3DF08BA25872B644A1421B9F085B1829615AE36AFA@xxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> > Orbital gateway says this is what they are receiving on their
> server:
> > Instead of this (from other successful posts in the program using
> the same
> > call above)
> Are you saying you have two posts in the same program - one that works
> and one that doesn't?
> The first Orbital gateway shows that there appears to be some custom
> headers missing? In the successful one, the auth-xxxx: xxxxx would
> appear to be the security information and is not being sent?
> There was a discussion a year+ ago about paymentech that might be
> helpful.
> http://www.scottklement.com/archives/ftpapi/201003/msg00048.html
> BTW, including only the information after the error is a terrible
> debugging problem. How about you include the information in the debug
> before the error so we can see what you are sending or perhaps we
> could see a bit more code? Are you creating custom headers?
> ------------------------------
> Message: 5
> Date: Wed, 8 Jun 2011 09:45:52 +0200
> From: Bing@xxxxxxxxxx
> Subject: Base64
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Message-ID:
>
> <OFAE0AFD92.83173D98-ONC12578A9.0026B066-C12578A9.0029DF8E@xxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
> Hello
> I used httpapi a few times. It worked. Thanks!
> Now I have an UPS-project. Via XML/Webservices send I a shipment and
> get
> shipmentresponse back with a label that is encoded with base64. I
> downloaded your program BASE64_H and BASE64R4, and compiled BASE64R4.
> CRTRPGMOD MODULE(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QRPGLESRC)
> DBGVIEW(*LIST)
> CRTSRVPGM SRVPGM(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QSRVSRC)
> CRTBNDDIR BNDDIR(LIBHTTP/BASE64) AUT(*ALL)
> ADDBNDDIRE BNDDIR(LIBHTTP/BASE64) OBJ((LIBHTTP/BASE64R4 *SRVPGM))
> So long every thing is ok. When I compiled my own program, I got error
> message.
> Ownership of object QRNFER in QTEMP type *USRSPC changed.
> Ownership of object QRNFEF in QTEMP type *USRSPC changed.
> Ownership of object UPSSND1 in QTEMP type *MODULE changed.
> Definition not found for symbol 'BASE64_DECODE'.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Please tell me which step I did wrong.
> Best regards
> Y. B. Chang
> -------------- next part --------------
> Hello
> I used httpapi a few times. It worked. Thanks!
> Now I have an UPS-project. Via XML/Webservices send I a shipment and
> get shipmentresponse back with a label that is encoded with base64.
> I
> downloaded your program BASE64_H and BASE64R4, and compiled
> BASE64R4.
> CRTRPGMOD MODULE(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QRPGLESRC)
> DBGVIEW(*LIST)
> CRTSRVPGM SRVPGM(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QSRVSRC)
> CRTBNDDIR BNDDIR(LIBHTTP/BASE64) AUT(*ALL)
> ADDBNDDIRE BNDDIR(LIBHTTP/BASE64) OBJ((LIBHTTP/BASE64R4 *SRVPGM))
> So long every thing is ok. When I compiled my own program, I got
> error
> message.
> Ownership of object QRNFER in QTEMP type *USRSPC changed.
> Ownership of object QRNFEF in QTEMP type *USRSPC changed.
> Ownership of object UPSSND1 in QTEMP type *MODULE changed.
> Definition not found for symbol 'BASE64_DECODE'.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Please tell me which step I did wrong.
> Best regards
> Y. B. Chang
> ------------------------------
> Message: 6
> Date: Wed, 08 Jun 2011 03:38:01 -0500
> From: Scott Klement<klemscot@xxxxxxxxxxxx>
> Subject: Re: Base64
> To: HTTPAPI and FTPAPI Projects<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:<4DEF34E9.4000308@xxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> I don't know which step you did wrong.
> Please verify that the BASE64R4 member in QSRVSRC has a line like:
> EXPORT SYMBOL(base64_decode).
> Check that base64_decode is exported using the DSPSRVPGM command?
> Did you include the BASE64 binding directory when you compiled your
> program?
> On 6/8/2011 2:45 AM, Bing@xxxxxxxxxx wrote:
> >
> > Hello
> > I used httpapi a few times. It worked. Thanks!
> > Now I have an UPS-project. Via XML/Webservices send I a shipment
> and
> > get shipmentresponse back with a label that is encoded with
> base64. I
> > downloaded your program BASE64_H and BASE64R4, and compiled
> BASE64R4.
> > CRTRPGMOD MODULE(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QRPGLESRC)
> > DBGVIEW(*LIST)
> > CRTSRVPGM SRVPGM(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QSRVSRC)
> > CRTBNDDIR BNDDIR(LIBHTTP/BASE64) AUT(*ALL)
> > ADDBNDDIRE BNDDIR(LIBHTTP/BASE64) OBJ((LIBHTTP/BASE64R4
> *SRVPGM))
> > So long every thing is ok. When I compiled my own program, I got
> error
> > message.
> > Definition not found for symbol 'BASE64_DECODE'.
> > Program UPSSND1 in library SYENDRE not created.
> > Compilation failed. Program UPSSND1 not created in library
> SYENDRE.
> ------------------------------
> Message: 7
> Date: Wed, 8 Jun 2011 11:05:15 +0200
> From: "Luciano Vigna"<luciano.vigna@xxxxxxxxx>
> Subject: R: Base64
> To: "'HTTPAPI and FTPAPI Projects'"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:<002d01cc25bb$2ed2c9e0$8c785da0$@vigna@libero.it>
> Content-Type: text/plain; charset="iso-8859-1"
> Hi Chang,
> Sorry for my simply question, but did you insert these statements in
> your
> program:
> h BNDDIR('HTTPAPI':'BASE64':'QC2LE')
> and / or
> /copy qrpglesrc,base64_h
> I have merged BASE64 in my source library, I think that you can check
> my
> compile operations:
> CRTRPGMOD MODULE(xx/BASE64R4)
> SRCFILE(xx_SRC/QRPGLESRC)
> DBGVIEW(*LIST)
>
> CRTSRVPGM SRVPGM(xx/BASE64R4)
> SRCFILE(xx_SRC/QSRVSRC)
>
> CRTBNDDIR BNDDIR(xx/BASE64)
>
> ADDBNDDIRE BNDDIR(xx/BASE64)
> OBJ((xx/BASE64R4 *SRVPGM))
> For me work very well, hope this serve,
> Regards
> Luciano
> -----Messaggio originale-----
> Da: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Per conto di
> Bing@xxxxxxxxxx
> Inviato: mercoled? 8 giugno 2011 09:46
> A: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Oggetto: Base64
> Hello
> I used httpapi a few times. It worked. Thanks!
> Now I have an UPS-project. Via XML/Webservices send I a shipment and
> get
> shipmentresponse back with a label that is encoded with base64. I
> downloaded
> your program BASE64_H and BASE64R4, and compiled BASE64R4.
> CRTRPGMOD MODULE(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QRPGLESRC)
> DBGVIEW(*LIST)
> CRTSRVPGM SRVPGM(LIBHTTP/BASE64R4) SRCFILE(LIBHTTP/QSRVSRC) CRTBNDDIR
> BNDDIR(LIBHTTP/BASE64) AUT(*ALL) ADDBNDDIRE BNDDIR(LIBHTTP/BASE64)
> OBJ((LIBHTTP/BASE64R4 *SRVPGM))
> So long every thing is ok. When I compiled my own program, I got error
> message.
> Ownership of object QRNFER in QTEMP type *USRSPC changed.
> Ownership of object QRNFEF in QTEMP type *USRSPC changed.
> Ownership of object UPSSND1 in QTEMP type *MODULE changed.
> Definition not found for symbol 'BASE64_DECODE'.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Program UPSSND1 in library SYENDRE not created.
> Compilation failed. Program UPSSND1 not created in library SYENDRE.
> Please tell me which step I did wrong.
> Best regards
> Y. B. Chang
> ------------------------------
> ----------------------------------------------------------------------
> -
> This is the FTPAPI mailing list digest. To unsubscribe, go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
> End of Ftpapi Digest, Vol 60, Issue 11
> **************************************
> _________________________________________________________________
>
> P before printing this message, please consider our environment
> CONFIDENTIALITY NOTICE
>
> This e-mail message, including any attachments, is for the sole use of
> the intended recipients(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact
> the sender by reply e-mail and destroy all copies of the original
> message.
>
>
>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------