When I'm trying to create message using CURL:
(example from here: http://stocktwits.com/developers/docs/api#messages-create-docs)
curl https://api.stocktwits.com/api/2/messages/create.json -F access_token=<access_token> -F body="Creating a new message with a chart. \$ticker" -F chart="http://i.imgur.com/vMlZa.gif"
everything works correctly
But when I'm replacing chart and trying another request:
curl https://api.stocktwits.com/api/2/messages/create.json -F access_token=<access_token> -F body="Creating a new message with a chart. \$ticker" -F chart="https://s3.amazonaws.com/tradingview/v/VA7nHUXP.png"
I get response:
{"response":{"status":422},"errors":[{"message":"We couldn't recognize
the image format. Format must be one of: image/jpeg image/pjpeg
image/png image/x-png image/gif"}]}
So, I've checked 'Content-Type': Content-Type: image/png.
What else can be wrong? Why StockTwits don't works with my image?
Thanks)
This issue has been fixed. There was an error on our side where image URL's that used HTTPS were being blocked.
Related
Unable to send Custom headers for zap-api-scan.py, headers are declared in options.prop
I want to use zap to scan a rest API endpoint which requires Authorization & X-api-key header.
To specify the header, I have configured these in options.prop file.
But when I run
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-weekly zap-api-scan.py -t <API URL> -f openapi -z "-configfile /zap/wrk/options.prop"
I feel prop file is not getting picked. I get 401 error, as my Authorization token is not picked up.
Below is how my options.prop file looks
replacer.full_list(0).description=Authorization
replacer.full_list(0).enabled=true replacer.full_list(0).matchtype=REQ_HEADER
replacer.full_list(0).matchstr=Authorization
replacer.full_list(0).regex=false
replacer.full_list(0).replacement=<Token>
replacer.full_list(1).description=x-api-key
replacer.full_list(1).enabled=true
replacer.full_list(1).matchtype=REQ_HEADER
replacer.full_list(1).matchstr=x-api-key
replacer.full_list(1).regex=false
replacer.full_list(1).replacement=<Value>
I am trying to download the logs of a particular workflow in github.
I have referenced the following link for the same.
However I am getting 302 as response code.
Not sure what the issue here is. Its not downloading logs as expected
curl -v -u username:$token -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/ORGANIZATION/REPOSITORY/actions/runs/319282523477/logs
.
.
< HTTP/1.1 302 Found
< Date: Wed, 21 Oct 2020 07:47:13 GMT
< Content-Type: text/html;charset=utf-8
.
As per the same documentation that you mentioned:
Gets a redirect URL to download a plain text file of logs for a workflow job. This link expires after 1 minute. Look for Location: in the response header to find the URL for the download
Response
Status: 302 Found
So you might have already got the url to download the logs as the response has a 302 http status. Please check for the Location: response header, which should give you the url that you need to download the logs.
As a side note to Madhu Bhat's answer, you can simply add -L to your curl command to make it follow redirects.
(from curl --help)
-L, --location Follow redirects
While doing the 'POST' request to 'https://de.api.labs.sophos.com/analysis/file/static/v1', I am getting 'HTTP content length exceeded 10485760 bytes.' response.
I know there is a limit to file size we can upload, but earlier we used to get '{message: 'Request Too Long'}' for bigger files(e.g. b28e99d046ac108830a3f5cf0f8eb485b7ce1abafe4d516fba5b4c71cec57fed), which is easier to parse because of JSON.
I am trying to upload sample with sha256 'e102238100a8b97d22559065e3b19379757aeda932c36916d2c84a4178921854'.
Request-
curl -X POST \
https://de.api.labs.sophos.com/analysis/file/static/v1 \
-H 'Authorization: <redacted>' \
-H 'content-type: multipart/form-data' \
-F file=#/tmp/e102238100a8b97d22559065e3b19379757aeda932c36916d2c84a4178921854
So, is there any standard response we will get while uploading big sample size?
The best practice would be to check the response's status code before parsing the response body, so in your case, running curl with the -i or -v option would expose this information to you.
Due to infrastructural limitations, submitting an oversized file up to ~6MB results in a HTTP 413 response, and above that, you can get error messages like 'Remote end closed connection without response' or 'Broken pipe', without a status code.
While the file size restriction may be subject to change in the future, currently there are no plans to change this behaviour.
After setting up my API to upload files, I realised that there is a special case where you want to upload a picture (jpg), you defined the binary support at the API, but you get the following error:
The request signature we calculated does not match the signature you
provided. Check your AWS Secret Access Key and signing method.
Consult the service documentation for details.
The Canonical String for this request should have been
'PUT /test/vi-dummy-bucket/testImg2.jpg
content-type:application/x-www-form-urlencoded
host:qhweyos7z2.execute-api.us-west-1.amazonaws.com
x-amz-date:20170808T154441Z
x-amz-security-token: // security token string no quotes
content-type;host;x-amz-date;x-amz-security-token 5fa90f0 ...'
The String-to-Sign should have been
'AWS4-HMAC-SHA256\n20170808T154441Z
20170808/us-west-1/execute-api/aws4_request
f7a38fa ...'
The strange thing is that uploading simple text files works with the exact same api call, then only thing I have to change is
Content-Type 'text/plain'
and write a text in the raw portion of the request.
Not sure if this is a Content-Type issue or a Request Body Issue, if I leave everything in the working state (text/plain & text in the body) and just change the body to binary and set the image, I get the above error.
My API gateway is in us-west-1 region
My S3 bucket is in us-east-1 region
And the request I am using is:
PUT /test/vi-dummy-bucket/testImg2.jpg HTTP/1.1
Host: qhwe7z2.execute-api.us-west-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
X-Amz-Security-Token: FQoDYX ...
X-Amz-Date: 20170808T154441Z
Authorization: AWS4-HMAC-SHA256
Credential=ASIAJICO6JFTJWN7A/20170808/us-west-1/execute-
api/aws4_request, SignedHeaders=content-type;host;x-amz-date;x-amz-
security-token,
Signature=6a792 ... Cache-Control: no-cache
Postman-Token: e9d1f730-f50b-7e27-70cc-c15a138d8cc6
(Binary Image)
This is another version of the request (same error):
PUT /test/vi-dummy-bucket/testImg2.jpg HTTP/1.1
Content-Type: image/jpeg
x-amz-security-token: FQoDY ...
x-amz-date: 20170808T190134Z
Authorization: AWS4-HMAC-SHA256
Credential=ASIAIZSP5YKVLJ3GVVQA/20170808/us-west-1/execute-
api/aws4_request, SignedHeaders=content-type;host;x-amz-date;x-amz-
security-token,
Signature=b2324 ...
Host: qhos7z2.execute-api.us-west-1.amazonaws.com
Connection: close
User-Agent: Paw/3.1.2 (Macintosh; OS X/10.12.6) GCDHTTPRequest
Content-Length: 823236
--- UPDATE ---
After implementing the sigV4 sigining manually using the generated SDK, the signature is no longer an issue.
The only problem left, is that the generated SDK only accepts a string as the "body", so I have to convert the file to a binary string. Then it passes correctly and a file is created in S3, but the size is now double and its not viewable, as if the binary string wasn't converted back to the binary file. So frustrating...
BTW, I've already tried PASSTHROUGH and CONVERT_TO_BINARY.
Updated: It looks like this may be related to a known error in Postman. For reference here is a related SO question: AWS Signature Error using Postman to access the AWS API Gateway when posting a binary
and here is the bug report for Postman: https://github.com/postmanlabs/postman-app-support/issues/3232
Does the request work if you use an alternate rest client and/or a command line utility like curl or httpie?
If you configured the binary support you should probably set the Content-Type to match the binary content you're sending.
From what you've posted you're sending the binary content with Content-Type application/x-www-form-urlencoded but if the body is actually a binary jpeg file I'd expect that you should be sending Content-Type image/jpeg
Problem
I'm testing a wsdl application with a remote server, so I can't have any influence on the requesting mechanism.
While testing with it, I get this log messages.
DEBUG:spyne.protocol.soap.soap11:ValueError: Deserializing from unicode strings
with encoding declaration is not supported by lxml.
DEBUG:spyne.protocol.xml:Validated ? False
40.50.60.70 - - [14/Jul/2016 16:58:42] "POST /?WSDL HTTP/1.1" 500 480
So the problem seems to be, that my remote server doing it's requests in a utf-8 encoded string, but I'm not able to reproduce it on my local machine. There I'm doing this with curl, which has a charset=utf-8 encoding in it's header and a input xml, wich has encoding='UTF-8' in it's`-tag too.
$ curl -X POST -H "Content-Type: text/xml; charset=utf-8" -d #request.xml
http://localhost:8000 > response.xml
Approaches
I tried to set an event_listener at the process which builds the wsdl, to maybe get a chance to manipulate the input string with ctx.in_string or something else.
MyService.event_manager.add_listener('wsdl_document_built', _on_wsdl_document_built)
MyService.event_manager.add_listener('document_built', _on_document_built)
application.event_manager.add_listener('wsdl_document_built', _on_wsdl_document_built)
application.event_manager.add_listener('document_built', _on_document_built)
But there was no execution of my added functions.
Also i searched unseccessful the docs for a type of configuration, to pre decode it.
So my question is how to force some kind of encoding of the incoming request xml?