I have to integrate a 3rd party system into my PHP app. I'm using cURL. The documentation says I have to send a soap envelope to the server, but in their example I found the following HTTP header as a correct request:
POST /CLI/ HTTP/1.1
Host: example.com
What's that CLI in the header? How can I send such a request from PHP?
Thanks for your help.
It's just the resource being requested,
GET /index.php
POST /index.php
IN your case: POST http://example.com/CLI/
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
Related
PHP 7.4, Windows Server 2012, IIS8
I'm using the DocuSign PHP SDK method createEnvelope, which sends the envelope object to their server. The URL is
https://demo.docusign.net/restapi/v2.1/accounts/cheese-burger/envelopes
with these headers
X-DocuSign-SDK: PHP
Authorization: Bearer ee-i-ee-i-oh
Accept: application/json
Content-Type: application/json
I'm successfully using the JWT key for, say, getUserInfo, but when I submit the envelope I get
HTTP/1.0 301 Moved Permanently
back. As far as I can tell, the envelope is created correctly, I know the JWT key works, and account id is correct. Any insight as to why I'm getting a 301 redirect?
#matt clark supplied the answer in the comments--the 301 response header helped the OP realize that he was missing the protocol section of the URL.
we're using a custom built cart system and during high loads our payment system (Worldpay) times out.
When this happen we receive an email containing the POST request that failed, and this is a .txt file done like the following:
POST /index.php?xxx=yyy&zzz=xxx HTTP/1.0
Content-Length: 917
Host: ourdomain.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
parameter1=value¶meter2=value2
How can I actually quickly resend this request to my server so it can register the payment now that the load is more normal? I have this in a .txt file, is there a quick way to do it using this file as it is? Curl? Browsers? In a way so I can see the response to check that all is ok.
Thanks so much!
Depending on the needs you have exposed, it is likely that tools such as POSTMAN could help you, allow you to send http requests through an intuitive interface, you can use the various parameters, that are sent to you in the file you mentioned and run the same request check for any errors.
I'm building an api that receives incoming webhooks from external parties. Post requests to my application lack a body in some cases. In my logs I see the incoming request with the following header:
Accept: */*
Content-Length:
Content-Type: application/json
As you can see the content-length is empty.
I cannot reproduce the problem. What I've tried thus far:
The request payload is only missing coming from a specific third party. If however, I provide this third party with a different callback url like request bin, the payload is not missing.
Connected this party source to our test environment. Which has exactly the same configuration (checked the entire php.ini) and the same version of our software. On our test server, requests are received with payload.
When sending post requests with Postman to our production environment, webhooks are received with payload.
Both test and production are https. I've tried sending http requests to our production server to see what happens, and I get an error as expected and no received headers in our logs.
Checked the php post_max_size, which is on 24M.
When creating a callback.php file in my public folder, and have the third party send it's webhooks to this destination, I am able to write the results to a log with the following code, which includes a payload. If I to output php://input later on in my Laravel application, it doesn't work:
$postdata = file_get_contents("php://input");
$file = fopen("webhook.log","w");
echo fwrite($file,$postdata);
fclose($file);
Both servers are running on the same php version (php7), and I am at a loss as to what to try next.
Found it! The problem was a port 80 to 443 redirect in a vhost configuration. I earlier dismissed redirects - which seem to be a common source of missing payloads in post requests - as possible cause; I had made a test script which succesfully received payloads on this very same server.
However, I had placed this test script in the servers public folder, which was not subject to the same redirects as was the root of my application. After removing the redirect, payloads where received as expected.
I'm using AWS API Gateway and passing the requests as HTTP Proxy to my nginx/php-fpm server.
on my server i print all the headers that arrived from the HTTP POST request.
on AWS:
added "Location" header under "Method Request" HTTP Request Headers
mapped "Location" header under "Integration Request" HTTP Headers:
Name: Location
Mapped from: method.request.header.Location
i'm using postman to send the POST request with additional headers but the header is not forwarded...any idea?
Can you see in the logs for the request (either in the console on the 'Test' page, or in CloudWatch Logs on the deployed API) if the headers are being sent to the endpoint? There should be verbose logs in the 'Test' page that tell you exactly what is being sent to/from the endpoint.
And is it all headers for you or just 'Location'?
I'm accessing the Magento SOAP API v2 with PHP's SoapClient
$soap_client = new SoapClient($wsdl_url, array('trace' => 1));
The wsdl url is http://www.example.org/index.php/api/v2_soap/?wsdl=1
Opening the url in the browser results in a valid xml document.
However when I access that same url with the SoapClient I get the following error message from $soap_client->__getLastResponse():
Invalid webservice adapter specified.
Looking at the request headers with $soap_client->__getLastRequestHeaders() shows that the call is being redirected to http://www.example.org/api/v2_soap/index/:
POST /api/v2_soap/index/ HTTP/1.1
Host: www.example.org
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.3
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:Mage_Api_Model_Server_V2_HandlerAction"
Content-Length: 542
Calling that url (http://www.example.org/api/v2_soap/index/) in the browser outputs the same error message that the SoapClient returns (Invalid webservice adapter specified.)
How is it possible that the SoapClient is being redirected while a normal http request works fine?
Any help greatly appreciated
The effect of MultiViews is as follows: if the server receives a
request for /some/dir/foo, if /some/dir has MultiViews enabled, and
/some/dir/foo does not exist, then the server reads the directory
looking for files named foo.*, and effectively fakes up a type map
which names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one of
them by name. It then chooses the best match to the client's
requirements.
MultiView Docs