I'm using curl (through symfony's plugin sfWebBrowser along with sfCurlAdapter), and I'm trying to do a very simple POST request on an https url.
Doing this with a normal browser gives 200 OK, whereas curl gets a "400 Bad Request" error.
I used the verbose option on curl, and here is what I got :
* About to connect() to preprod-ppps.paybox.com port 443 (#0)
* Trying 195.101.99.73... % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected
* Connected to preprod-ppps.paybox.com (195.101.99.73) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=FR; postalCode=78280; ST=Yvelines; L=GUYANCOURT; street=11A rue Jacques Cartier; O=PAYBOX SERVICES; OU=0002 431408608; OU=X509 Omnidomaine TBS; CN=*.paybox.com
* start date: 2009-08-17 00:00:00 GMT
* expire date: 2011-10-03 23:59:59 GMT
* subjectAltName: preprod-ppps.paybox.com matched
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=AAA Certificate Services
* SSL certificate verify ok.
> POST /PPPS.php HTTP/1.1
Host: preprod-ppps.paybox.com
Accept: */*
Accept-Encoding: gzip,deflate
< HTTP/1.1 400 Bad Request
< Date: Wed, 06 Apr 2011 11:56:35 GMT
< Server: HttpServer
< Content-Length: 226
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
100 226 100 226 0 0 793 0 --:--:-- --:--:-- --:--:-- 1013* Closing connection #0
I also tried setting every header I could see with firebug, so that the request is the same in both cases, without success.
What went wrong?
It seems like you have no post-data with your request. You probably have not set up your curl transfer properly.
You should have at least a Content-Length header with your POST.
Maybe they block curl as they think it is a bot trying to attack their system. They will be able to detect the user agent from the headers you send with your request.
Related
I'm trying to integrate authorize.net (AIM) using the official PHP SDK v2.0.0 and I'm seeing some strange behaviors:
curl_exec() returns false even when the request is successful and CURLOPT_RETURNTRANSFER is set to true.
curl_errno is returns 7 (Failed to connect() to host or proxy) for the same request.
I know request is successful since:
I can see the transaction is successfully recorded at authorize.net
Setting CURLOPT_RETURNTRANSFER to false causes the JSON response from authorize.net to be printed
curl_getinfo() shows HTTP status code = 200
Anyone experience this type of behavior with cURL? I'm not sure what I'm missing.
EDIT: Added output with CURLOPT_VERBOSE set
* Trying 198.241.206.22:443...
* Connected to apitest.authorize.net (198.241.206.22) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/app/demo/assets/lib/anet_sdk_2.0.0/lib/ssl/cert.pem
CApath: none
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=Foster City; O=Authorize.Net; CN=*.authorize.net
* start date: Feb 5 20:44:08 2020 GMT
* expire date: Mar 15 21:14:08 2021 GMT
* subjectAltName: host "apitest.authorize.net" matched cert's "*.authorize.net"
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K
* SSL certificate verify ok.
> POST /xml/v1/request.api HTTP/1.1
Host: apitest.authorize.net
Accept: */*
Content-Type: text/json
Content-Length: 1458
* upload completely sent off: 1458 out of 1458 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< X-OPNET-Transaction-Trace: a2_fe4a070f-cf07-47d7-8e9e-c8a703920de5-5628-7089051
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
< Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
< Access-Control-Allow-Origin: *
< Strict-Transport-Security: max-age=31536000
< X-Cnection: close
< Date: Sat, 12 Sep 2020 10:40:48 GMT
< Content-Length: 512
<
* Connection #0 to host apitest.authorize.net left intact
I think the root cause of this is my general misunderstanding of how the Facebook API works, so I hope someone with a bit more knowledge can point me in right direction.
All I'm trying to do is return a facebook gallery for one of our clients onto two different pages, hosted on different servers. I use this format on one page:
$albums = json_decode( file_get_contents('http://graph.facebook.com/'.$facebook_ID.'/albums') );
And this works fine, I get what I need. However, doing this on the other site gives me this error:
"message":"An access token is required to request this resource."
Does it really need an access token if all I am doing is requesting a public gallery? To further confuse me, if I simply put this in my browser:
http://graph.facebook.com/$facebook_ID/albums
I get all the required info. This tends me towards thinking it's not a domain issue?
Thanks!
--- EDIT ---
Here's some more info with curl.
First - the request that works, from my local box:
* About to connect() to graph.facebook.com port 80 (#0)
* Trying 69.171.242.27...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to graph.facebook.com (69.171.242.27) port 80 (#0)
> GET /370438539411/albums HTTP/1.1
> User-Agent: curl/7.29.0
> Host: graph.facebook.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Cache-Control: private, no-cache, no-store, must-revalidate
< Content-Type: application/json; charset=UTF-8
< ETag: "2829e31bfef4b737cdb31aab0f73c8ad35826012"
< Expires: Sat, 01 Jan 2000 00:00:00 GMT
< Pragma: no-cache
< X-FB-Rev: 801567
< X-FB-Debug: /uN6PrzpTWLLaJOn8vuww0ECYjineJN6P9w/DvvVczY=
< Date: Wed, 01 May 2013 12:01:26 GMT
< Connection: keep-alive
< Content-Length: 35483
<
ALL THE THINGS
And then here is the request from our live server - an EC2 instance ( if this is relevant )
* About to connect() to graph.facebook.com port 80 (#0)
* Trying 173.252.101.26... % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected
* Connected to graph.facebook.com (173.252.101.26) port 80 (#0)
> GET /370438539411/albums HTTP/1.1
> User-Agent: curl/7.29.0
> Host: graph.facebook.com
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Access-Control-Allow-Origin: *
< Cache-Control: no-store
< Content-Type: application/json; charset=UTF-8
< Expires: Sat, 01 Jan 2000 00:00:00 GMT
< Pragma: no-cache
< WWW-Authenticate: OAuth "Facebook Platform" "invalid_token" "An access token is required to request this resource."
< X-FB-Rev: 801567
< X-FB-Debug: wSxKF5MlCAmEFf2BuYRBDotWWreR6/t5m5mebc8vDXw=
< Date: Wed, 01 May 2013 12:03:38 GMT
< Connection: keep-alive
< Content-Length: 112
<
^M 0 112 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{ [data not shown]
^M100 112 100 112 0 0 181 0 --:--:-- --:--:-- --:--:-- 212
* Connection #0 to host graph.facebook.com left intact
* Closing connection #0
{"error":{"message":"An access token is required to request this resource.","type":"OAuthException","code":104}}
(END)
There might be some or the other thing that might make or break access to public data like they way you are accessing. As you have already experienced this, I would like you to go safe on this and instead create an App and use an App Access Token to query for the public data instead of going to it directly as Facebook might in near future even change this..
I originally posted this at the Amazon SES forums here: https://forums.aws.amazon.com/thread.jspa?threadID=74561&tstart=0
But since the stackoverflow community is more active, I'll post it here :)
Basically I have a forecah loop around a cURL post (see bottom of post for script snippet). It works for a couple hundred posts, but then starts to fail for all the others. Here's the last successful post followed by the first of 100's of unsuccessful posts...
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5810
Expect: 100-continue
< HTTP/1.1 200 OK
< x-amzn-RequestId: 4a0f8f18-cb5f-11e0-8364-b14fdafc0888
< Content-Type: text/xml
< Content-Length: 326
< Date: Sat, 20 Aug 2011 19:04:55 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
The the failures start....
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5806
Expect: 100-continue
< HTTP/1.1 400 Bad Request
< x-amzn-RequestId: 4b8f29db-cb5f-11e0-b9af-33e5c8fc863b
< Content-Type: text/xml
< Content-Length: 347
< Date: Sat, 20 Aug 2011 19:04:58 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
Here's the script snippet
foreach($JSONarray['DATABASE'] as $E)
{
if ((array_diff($E['LISTS'], $FILTER) != $E['LISTS']) && $E['STATUS'] == "CONF")
{
$MAIL = "Action=SendEmail&Source=".$FROME."&ReturnPath=".$BOUNCE."&Destination.ToAddresses.member.1=".$TOE."&Message.Subject.Data=".$SUBE."&Message.Body.Html.Data=".$BODYE;
//curl
$aws = curl_init();
curl_setopt($aws, CURLOPT_POSTFIELDS, $MAIL);
curl_setopt($aws, CURLOPT_HTTPHEADER, $headers);
curl_setopt($aws, CURLOPT_HEADER, false);
curl_setopt($aws, CURLOPT_URL, $url);
curl_setopt($aws, CURLOPT_RETURNTRANSFER, true);
curl_setopt($aws, CURLOPT_VERBOSE, true);
curl_setopt($aws, CURLOPT_STDERR, $SESLOG);
curl_exec($aws);
curl_close($aws);
}
}
Any ideas?
Could it be a DOS prevention mecanism kicking in? How about putting some sleeps into your code? I would definitely put some safeguards against potential DOS attacks if I were Amazon..
Just a guess, though...
I figured out the problem:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>RequestExpired</Code>
<Message>Request timestamp: Mon, 22 Aug 2011 15:49:11 UTC expired. It must be within 300 secs/ of server time.</Message>
</Error>
<RequestId>0e3899cb-ccd7-11e0-9f09-c5d12d442026</RequestId>
</ErrorResponse>
My headers were set-up outside the forecah loop around curl. Doh! So I just moved that bit of code into the loop to solve the time-out problem.
The trouble showed itself yesterday - getting following answer from curl (called in php script by curl_exec):
$<errno>35</errno>
$<error>Unknown SSL protocol error in connection to w3s.webmoney.ru:443 </error>
That bug happens only sometimes, something around 4-5 valid responses to one invalid with 35 error. Before yesterday application was handling those requests correctly for a very long time.
Hope someone will give me a hint about possible reasons of that bug.
P.S. We are suffering from internet connection problems lately, can it be somehow connected to that bug?
Upd:
Setting verbose output to true made curl to write following log:
* About to connect() to w3s.webmoney.ru port 443 (#0)
* Trying 82.198.171.158... * connected
* Connected to w3s.webmoney.ru (82.198.171.158) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: ${path}/WebMoneyCA.crt
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=RU; O=WebMoney Transfer; OU=WebMoney Web Service; CN=w3s.webmoney.ru
* start date: 2010-06-07 10:03:43 GMT
* expire date: 2012-06-07 10:13:43 GMT
* common name: w3s.webmoney.ru (matched)
* issuer: OU=WM Transfer Certification Services; O=WM Transfer Ltd; CN=WebMoney Transfer Root CA
* SSL certificate verify ok.
> POST /asp/XMLPurses.asp HTTP/1.1
Host: w3s.webmoney.ru
Accept: */*
Content-Length: 281
Content-Type: application/x-www-form-urlencoded
< HTTP/1.1 200 OK
< Date: Fri, 10 Dec 2010 13:00:04 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Content-Length: 4423
< Content-Type: text/xml; Charset=windows-1251
< Expires: Fri, 10 Dec 2010 13:00:04 GMT
< Set-Cookie: ASPSESSIONIDQADQDTAQ=FJMNECHBENFFAADHEHPFOKAE; path=/
< Cache-control: private
<
* Connection #0 to host w3s.webmoney.ru left intact
* Closing connection #0
* About to connect() to w3s.webmoney.ru port 443 (#0)
* Trying 212.158.173.158... * connected
* Connected to w3s.webmoney.ru (212.158.173.158) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: ${path}/WebMoneyCA.crt
CApath: /etc/ssl/certs
* Unknown SSL protocol error in connection to w3s.webmoney.ru:443
* Closing connection #0
Upd:
The trouble was not on our side. The problem was hidden somewhere in w3s.webmoney.ru, in 212.158.173.158 server. I'll add more details about the bug if information will be available.
Got the following response from WM support people:
"There are four IP addresses on hostname w3s.webmoney.ru. When a request ends up on 212.158.173.158, SSL is getting killed by a piece of anti-DDoS hardware at the provider's. The problem was localized, they're now trying to fix it."
I am using curl to send xml requests to API from Emailvision. I am having trouble lately where some requests result in "500 Internal Server Error", while others are sent without any errors.
The output of verbose is pasted below, can someone please help me interpret what might be causing the error.
* About to connect() to api.notificationmessaging.com port 443
* Trying 81.92.116.8... * connected
* Connected to api.notificationmessaging.com (81.92.116.8) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=FR/ST=Hauts de Seine/L=Clichy/O=Emailvision/OU=Provided by TBS INTERNET http://www.tbs-certificats.com//CN=*.notificationmessaging.com
* start date: 2008-09-20 09:09:15 GMT
* expire date: 2010-09-20 09:09:15 GMT
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
* SSL certificate verify ok.
POST /NMSXML HTTP/1.1
Host: api.notificationmessaging.com
Accept: */*
Content-Length: 2177
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
HTTP/1.1 100 Continue
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2177 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 200 OK
Date: Wed, 15 Sep 2010 05:15:53 GMT
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Content-Type: application/xml;charset=utf-8
Content-Length: 82
Connection: close
100 2259 0 82 100 2177 969 25745 --:--:-- --:--:-- --:--:-- 80629* Closing connection #0
* About to connect() to api.notificationmessaging.com port 443
* Trying 81.92.116.8... * connected
* Connected to api.notificationmessaging.com (81.92.116.8) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=FR/ST=Hauts de Seine/L=Clichy/O=Emailvision/OU=Provided by TBS INTERNET http://www.tbs-certificats.com//CN=*.notificationmessaging.com
* start date: 2008-09-20 09:09:15 GMT
* expire date: 2010-09-20 09:09:15 GMT
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
* SSL certificate verify ok.
POST /NMSXML HTTP/1.1
Host: api.notificationmessaging.com
Accept: */*
Content-Length: 21942
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
HTTP/1.1 100 Continue
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 21942 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 500 Internal Server Error
Date: Wed, 15 Sep 2010 05:15:52 GMT
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Content-Type: text/xml
Content-Length: 0
Connection: close
100 21942 0 0 100 21942 0 216k --:--:-- --:--:-- --:--:-- 535k* Closing connection #0
* About to connect() to api.notificationmessaging.com port 443
* Trying 81.92.116.8... * connected
* Connected to api.notificationmessaging.com (81.92.116.8) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=FR/ST=Hauts de Seine/L=Clichy/O=Emailvision/OU=Provided by TBS INTERNET http://www.tbs-certificats.com//CN=*.notificationmessaging.com
* start date: 2008-09-20 09:09:15 GMT
* expire date: 2010-09-20 09:09:15 GMT
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
* SSL certificate verify ok.
POST /NMSXML HTTP/1.1
Host: api.notificationmessaging.com
Accept: */*
Content-Length: 11602
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
HTTP/1.1 100 Continue
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 11602 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 500 Internal Server Error
Date: Wed, 15 Sep 2010 05:15:52 GMT
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Content-Type: text/xml
Content-Length: 0
Connection: close
100 11602 0 0 100 11602 0 118k --:--:-- --:--:-- --:--:-- 306k* Closing connection #0
* About to connect() to api.notificationmessaging.com port 443
* Trying 81.92.116.8... * connected
* Connected to api.notificationmessaging.com (81.92.116.8) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=FR/ST=Hauts de Seine/L=Clichy/O=Emailvision/OU=Provided by TBS INTERNET http://www.tbs-certificats.com//CN=*.notificationmessaging.com
* start date: 2008-09-20 09:09:15 GMT
* expire date: 2010-09-20 09:09:15 GMT
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
* SSL certificate verify ok.
POST /NMSXML HTTP/1.1
Host: api.notificationmessaging.com
Accept: */*
Content-Length: 2178
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
HTTP/1.1 100 Continue
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2178 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 HTTP/1.1 200 OK
Date: Wed, 15 Sep 2010 05:15:53 GMT
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Content-Type: application/xml;charset=utf-8
Content-Length: 82
Connection: close
100 2260 0 82 100 2178 777 20644 --:--:-- --:--:-- --:--:-- 45375* Closing connection #0
* About to connect() to api.notificationmessaging.com port 443
* Trying 81.92.116.8... * connected
* Connected to api.notificationmessaging.com (81.92.116.8) port 443
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=FR/ST=Hauts de Seine/L=Clichy/O=Emailvision/OU=Provided by TBS INTERNET http://www.tbs-certificats.com//CN=*.notificationmessaging.com
* start date: 2008-09-20 09:09:15 GMT
* expire date: 2010-09-20 09:09:15 GMT
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
* SSL certificate verify ok.
POST /NMSXML HTTP/1.1
Host: api.notificationmessaging.com
Accept: */*
Content-Length: 2178
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
HTTP/1.1 100 Continue
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2178 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
And below is the curl snippet I am using to make requests.
curl_setopt($ch,
CURLOPT_URL,'https://api.notificationmessaging.com/NMSXML');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_POSTFIELDS, $sXML);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 600);
curl_setopt($ch, CURLOPT_VERBOSE, TRUE);
curl_setopt($ch, CURLOPT_NOPROGRESS, 0);
$res = curl_exec($ch);
Can someone please help.
Thanks
UPDATE:
Found that the problem is with some characters like รข in the xml, as pointed out by Mark. Now is there a way to remove/convert all chars not recognized in xml?
A 500 means there is a programming error with their system, not yours. It could be caused by you sending bad parameters, but they should be dealing with that in a different way.
I'd inform the company that something you are doing is causing a 500, and they should be able to fix it on their end.