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.
Related
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 have come across this header for the first time and not sure what it does or mean. I have searched around and couldn't find what I was looking for.
I am trying to consume a SOAP API using PHP SoapClient class and it's returning an empty response and these response headers. Also, no exception is thrown.
HTTP/1.1 200 OK
X-Backside-Transport: FAIL FAIL,FAIL FAIL
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml
Date: Tue, 21 Jun 2016 20:09:50 GMT
X-Client-IP: xx.xxx.xxx.xxx
Any help is appreciated.
It seems that the web service you're trying to communicate is behind the xml firewall (probably IBM DataPower, it does send X-Backside-Transport header on failere) and blocks the error response (aka. fault message). This is the default behaviour for the xml firewalls. Root cause can be malformed soap message (i.e.: wrong data type) or an server site exception.
In order to solve the problem, you should contact with the web service owner.
I've seen this in the past when communicating with IBM Backends, in my experience it has also been joined with a HTTP 401 Unauthorised.
The reason for the error on my side was because of duplicate headers (e.g. sending the same head twice...)
Hope this helps.
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
I am trying to better understand OAuth by experimenting with the twitteroauth php library.
It is my understanding that the way to authenticate over OAuth is to make use of an 'Authorize' header when using cUrl. However, examining the source for the twitteroauth library, I can see that the header is set as so for post requests:
curl_setopt($ci, CURLOPT_HTTPHEADER, array('Expect:'));
And the parameters that should be set in the 'Authorize' header are actually being set in the post body instead in the line:
curl_setopt($ci, CURLOPT_POSTFIELDS, $postfields);
What is the reason for it being done this way? When in the twitter API guidelines is specifies the following implementation for the header:
POST /1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Authorization:
OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318622958",
oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
oauth_version="1.0"
Content-Length: 76
Host: api.twitter.com
status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
A client may add the HTTP Expect header to tell the server "hey, I expect you to behave in a certain way". For some reason, Twitter's implementation wants you to expect nothing. I ran into this with my own home-grown implementation. I'm not sure why Twitter wants this header.
You may present your credentials and signature in the POST variables, or in the header. Both will work as long as the correct variables are set (oauth_consumer_key, oauth_nonce, oauth_signature, oauth_signature_method, oauth_timestamp, and oauth_token).
I find setting the Authorization header to be cleaner because it does not depend upon the request method (GET, POST, PUT, etc). But Twitter handles both cases perfectly fine. If that's how they implemented it in their library, so be it.
I am having some problems trying to get a post request to work from a payment provider (WorldPay) to my host server. Basically WorldPay does a callback to a script on my website if/when a transaction is successful. Problem is the post request isn’t getting to my script – we just get a 408 timeout.
This is the request sent from WorldPay below:
POST /index.php?route=payment/worldpay/callback HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: www.mysite.com
Content-Length: 711
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
authAmountString=%26%23163%3B3.49&_SP.charEnc=UTF-8&desc=testItem&authMode=A
And this is the response sent back from my hosts server:
HTTP/1.1 408 Request Timeout
Connection: Close
Pragma: no-cache
cache-control: no-cache
Content-Type: text/html; charset=iso-8859-1
I know this is a long shot but can anyone see anything wrong with anything above? To simplify things i replaced the php script with a basic html output which returned a hello world message and we still got a 408 so i’m pretty sure the script works. We have also had this error once or twice:
failed CAUSED BY invalid HTTP status line: >null<
Any help is greatly appreciated
Cheers
Paul
If the HTTP request you gave above is accurate, it seems as if the client is advertising a content length of 711 bytes, but the entity body does not seem to be 711 bytes long. That is why the server is timing out waiting for the rest of the data.
HTTP/1.1 408 Request Timeout,
pay attention to server config, if your host server is nginx, you can check "client_body_timeout" in nginx.conf