I have a problem with the response I get from the soap service.
I set the "SetSslClientCertPfx" with invoke method:
certificate name
password
I set the "SetRequestHeader" with invoke method:
Content-Type
text/xml; charset=UTF-8
I set the "SetRequestHeader" with invoke method:
SOAPAction
urloftheaction
Invoke method "PostXml":
Server link
blob with file content
utf-8
I check for errors with "get.LastErrorText"
I get the response with "get.bodyStr"
For the result, I have a char(32000) field. I tried increasing this to 64000 characters but that way I get an empty result. I also tried to replace the char field with the blob. That also didn't work. It's like the method itself is limited to 32000 chars.
I read that for large results I should use "LastStringResult" but it only works for MySQL. Is there a solution to my problem?
I'm assuming the content returned in the body of the HTTP response is XML? (or perhaps JSON?) In either case, the best thing to do is to avoid getting the returned content as a string. Let me explain...
For example, instead of calling response.GetBodyStr(), call response.GetBodyXml(xmlObj) (see https://www.chilkatsoft.com/refdoc/xChilkatHttpResponseRef.html#method4 )
The GetBodyXml method loads the response body into the XML object passed in the argument. Then your application can work with the contents of the XML via the Chilkat XML API, i.e parsing out the various parts as needed.
Related
I'm building a multi-exchange bot in C++ and I'm having one small problem. KuCoin exchange has proven to be frustrating to say the least, one of the headers is a signature header where you encode the string with HMAC sha256 and then encode THAT with base64. However I'm not concerned with the encoding, I can do all that. What is stumping me is the string KuCoins API is expecting, I've scoured their documentation 100 times over and I still can't get it right, here are the instructions
For the header of KC-API-KEY:
Use API-Secret to encrypt the prehash string {timestamp+method+endpoint+body} with sha256 HMAC. The request body is a JSON string and need to be the same with the parameters passed by the API.
After that, use base64-encode to encrypt the result in step 1 again.
I've attempted to craft this string in every way possible, and the documentation provides no examples on what a good string should look like, here are the strings I've crafted BEFORE encoding that DO NOT work.
EXAMPLE 1: 1616096476134POST/api/v1/orders?clientOid=55be5&side=BUY&symbol=BTC-USDT&type=MARKET&funds=0.005000
EXAMPLE 2: 1616099932367POST/api/v1/orders{"clientOid":"55be5","side":"BUY","symbol":"BTC-USDT","type":"MARKET","funds":"0"}
As you can see, in the 2nd example I tried to make the body a JSON string with all the correct parameters, but still, I'm getting a bad signature error returned. Literally all I need is to know what the string is supposed to look like so I can craft it properly. Thanks.
I take the assumption that your code works for a private request without parameters (like getting the balance for instance).
I also struggled a bit for POST requests, but managed to get it right after a few attempts. You need to dump the parameters as a JSON string without spaces, exactly like in your example 2.
Since that time, have you managed to solve it ? I have a code on my application that works if you are interested.
Also, don't forget to add in the headers of the curl request:
Content-Type: application/json
Solved with Kucoin support and pythone example.
The "body" also must be included in POST request.
Was:
reply = netman->post(req, "");
Become:
tradereply = trademan->post(req, data);
I want to return a pdf from a AWS Lambda function, and I use API Gateway for calling it from a any browser.
I have a aws lambda function in c# that returns an API Gateway Response which body is a pdf in base64 encoded string.
So far the endpoint returns a file with .pdf extension but not in binary. Instead, is a text file with the base64 string.
The headers i'm returning from the c# code are:
var headersDic = new Dictionary<string, string>();
headersDic.Add("Content-type", "application/pdf");
headersDic.Add("Content-disposition", "attachment; filename=file.pdf");
I converted manually the base64 string to binary file and opened it as a pdf, and it works, I mean, the base64 string is correct so I assume the problem is being the API Gateway.
In the integration response console of the API Gateway, I got this:
But i'm not able to make it work.
I also have binary media types enabled.
Actually, you do not have to disable Lambda Proxy Integration, nor do you have to specify "*/*" as a Binary Media Type, nor do you have to have your Lambda code convert the output to Base64, nor do you have to modify LambdaEntryPoint in order to get this to work.
Although some sources indicate that the "*/*" entry is necessary, the answer lies in the comment accompanying the Binary Media Types setting:
"API Gateway will look at the Content-Type and Accept HTTP headers to
decide how to handle the body."
In other words, for some odd reason, rather than just paying attention to the returned Content-Type in applying the Binary Media Types list, the gateway also takes into account the requesting client's Accept header. Most clients default to Accept:*/*, thus the origin of the workaround, and the most common explanation as to why this list doesn't seem to work. Not only does the client's Accept header seem to be given more credence than the returned Content-Type value here, there is no semantic assessment of "*/*". It is not evaluated as a wildcard, which should match any content type. Thus, an exact match of said value, literally "*/*", winds up being needed in the Binary Media Types list.
A simple solution (one which works for me) is to:
Have the client, instead of specifying "*/*" in its Accept header, specify the actual expected MIME type. (Do not specify multiple Accept types, as only the first listed type is evaluated.)
Include the same MIME type in the Binary Media Types list. Do not specify "*/*".
Have the Lambda function return a non-Base64-encoded binary file, specifying its actual MIME type in the Content-Type header.
For instance, in C#, by returning a FileContentResult from the ControllerBase.File() method, specifying the appropriate MIME content type, as in:
return File(pdfContents, "application/pdf"); //pdfContents contains raw binary data
API Gateway will match the data type to its Binary Media Types list and regard the returned data as binary. So far, I have not needed to insert RegisterResponseContentEncodingForContentType() in LambdaEntryPoint.Init().
I don't know exactly what I did, but I deleted the 'ALL' method, and created the 'GET' method with this config and now it works.
You also need to declare the content type like the following in your LambdaEntryPoint.cs
See this documentation: https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.AspNetCoreServer/README.md
You have to tell Lambda you're going to return something besides strings.
public class LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction
{
protected override void Init(IWebHostBuilder builder)
{
builder
.UseStartup<Startup>();
****IMPORTANT PART HERE****
RegisterResponseContentEncodingForContentType("application/pdf",
ResponseContentEncoding.Base64);
}
}
Response Headers
'Content-Type': 'application/pdf'
'Content-disposition', 'attachment; filename=fileName.pdf'
Response to Client
{
statusCode: 200
headers: responseHeader,
body: pdfContent.toString(base64),
isBase64Encoded: true,
}
API Gateway Binary Media Types
Hope it will help
Usually to retrieve a resource one uses:
GET http://ws.mydomain.com/resource/123212
But what if your item IDs are HTTP URIs?:
GET http://ws.mydomain.com/resource/http://id.someotherdomain.com/SGX.3211
Browsers replace two slashes with one, and the request turns into:
GET http://ws.mydomain.com/resource/http:/id.someotherdomain.com/SGX.3211
which will not work.
URI encoding the "http://id.someotherdomain.com/SGX.3211" -part results in HTTP 400 - Bad request.
Is there a best practice for handling this?
Edit:
Then of course if we would need to have (I don't at the moment) request in form:
resources/ID/collections/ID
and all IDs are HTTP URIs, things get out of hand... Possibly one could do something like this and parse the contents inside the curly braces:
resources/{http://id...}/collections/{http://id...}
Encode the other system's URI, and then pass the value as a query parameter:
GET http://ws.mydomain.com/resource?ref=http%3A%2F%2Fid.someotherdomain.com%2FSGX.3211
Ugly looking, but no one said that URIs used in a REST architecture have to be beautiful. :)
By the way, a GET actually looks like this when it's sent:
GET /resource?ref=http%3A%2F%2Fid.someotherdomain.com%2FSGX.3211 HTTP/1.1
Host: ws.mydomain.com
UPDATE: apparently you no longer have to encode "/" and "?" within a query component. From RFC 3986:
The characters slash ("/") and question mark ("?") may represent data
within the query component. Beware that some older, erroneous
implementations may not handle such data correctly when it is used as
the base URI for relative references (Section 5.1), apparently
because they fail to distinguish query data from path data when
looking for hierarchical separators. However, as query components are
often used to carry identifying information in the form of "key=value"
pairs and one frequently used value is a reference to another URI, it
is sometimes better for usability to avoid percent-encoding those
characters.
So you could legally do this:
GET /resource?ref=id.someotherdomain.com/SGX.3211 HTTP/1.1
Host: ws.mydomain.com
I'm working on a program dealing with cookies under the kohana's HMVC structure, and I find that Kohana has 3 ways to get/set the cookie. They are
Request::current()->cookie(), Response->cookie(), and the cookie class (Cookie::set(), get())
And PHP has a native setcookie() function and $_COOKIE to deal with cookies too.
Could anyone explain their differences and, what are the situations that they should be used respectively.
Request::cookie() prior to calling Request::execute() on the same object is used to set the cookies that will be send (or have been sent in case of the initial request) along with the rest of the request.
Request::cookie() during a Request::execute() will replace $_COOKIE.
Response::cookie() during a Request::execute() will replace setcookie().
Response::cookie() after a Request::execute() is used to get the cookies set back by the server.
The Cookie helper will sign your cookies and is used by HTTP_Header to set cookies set to the Response object in your initial Request object (see Response::send_headers() in index.php).
You probably do not want to use it yourself directly if you are trying to code HMVC safe.
Simplified code example: http://pastebin.com/9ZQxSXi9
Hi
I wanted to experiment with the restlet 2.0 library and the gpodder webservice but somehow i reached a point where I can't see the wood for the trees.
The service in the example requires HTTP authentication and to post some JSON content to a URL.
Nothing that complicated but somehow even though the debug view claims the request object to contain the necessary content the RESTful webservice's response leads me to believe the HTTP header of the request was missing the content.
Any ideas on what's the reason? Thanks in advance.
The problem is that that none of the implementation of WriterRepresentation I've seen (JsonRepresentation, JacksonRepresentation, XStreamRepresentation) set the size of the representation when an object is passed. So if you create a new JacksonRepresentation(map) the size is not calculated.
You have to compute manually the length of the map content and calling Representation.setSize().
Or, as I did, use a
new JsonRepresentation(" a json string... ");
This constructor is able to compute the size, of course, that's the string length, so the proper content-length header is set and everything works smooth.