The Docker Registry API Documentation (here) states that you can do:
https://index.docker.io/v1/images/088b4505aa3adc3d35e79c031fa126b403200f02f51920fbd9b7c503e87c7a2c/ancestry
However this (with several image ids I have tried) only yields a 404. Why?
You are using the incorrect domain. Note from the documentation example:
GET /v1/images/088b4505aa3adc3d35e79c031fa126b403200f02f51920fbd9b7c503e87c7a2c/ancestry HTTP/1.1
Host: registry-1.docker.io
Accept: application/json
Content-Type: application/json
Cookie: (Cookie provided by the Registry)
You should be using registry-1.docker.io, not index.docker.io. So your url should be:
https://registry-1.docker.io/v1/images/088b4505aa3adc3d35e79c031fa126b403200f02f51920fbd9b7c503e87c7a2c/ancestry
When I run this I no longer get a 404 but instead get an authorization error. This is because you need to auth against index.docker.io and then run your api against registry-1.docker.io.
It's not well documented - you may find this discussion helpful:
https://forums.docker.com/t/registry-hub-api-is-buggy/732
from the discussion:
registry-1.docker.io is the docker-registry used for storing images,
this API is public, but requires authorization.
index.docker.io is the "index" now called RegistryHub, this tags
endpoint is not public, and might change at any time. I would not use
this one, since it is for internal use only, and may change without
warning.
Related
When i try to test api with localhost:[port] it gives the invalid character in header ["Host"] console error. I am using dotnet core webApi. I cross checked the CORS configuration from api end it is fine. The issue is on the Postman side.
Postman version: v8.7.0
I had the same error being reported for any forked or created Postman requests:
Error: Invalid character in header content ["Host"]
The request URL was using a global parameter:
{{BaseUri}}/some/sort/of/resource
In the console logs the following was reported (URLs redacted):
Request Headers
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Cache-Control: no-cache
Postman-Token: 9d14e81d-1e21-44a2-93ed-2758f0ad24fa
Host: my.url.co.uk↵
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Note the ↵ character at the end of the Host Header.
The global BaseUri parameter did not appear to have a line break at the end of it. However, completely deleting said parameter and recreating it seems to have fixed the issue.
I also had same incident and I was able to find the error by exporting "My Workspace" content and open it from notepad++. Then change the encoding to "ANSI" from notepad++ (Encoding=> ANSI). You will notice special characters as below,
This can happen when you copy the url and paste in Postman and then try to edit it.
If you are getting this URL from someone what you can ask is to provide exported json file from postman. Then import it to your workspace.
I thought the issue was in a variable I was using because the error was telling me there's an invalid character in my host https://localhost:4431 which is exactly the value of my variable.
I figured out the invalid character was actually not in my variable but in the rest of the URL in my request.
Turns out, when copying endpoint names from the Swagger of my API, I was also copying an invisible character %E2%80%8B. I saw it when checking the API's console RequestPath:/%E2%80%8BmyEndpoint
Removing this invisible character solved the issue
Taken from question comments. by Fidel Garcia
I created the request again via Add Request menu and it works. I'm not sure if it is a problem with the update and old requests. The old one is still failing.
===================================================
It also worked for me. I created new request with the same parameters and it worked.
I created a requested with and wrote the parameters in headers. After wrong requested I changed it to correct one (post request and parameters in body) and got the error. After creating new request with correct configuration (post request parameters in body) it worked correctly.
In my case:
I removed the authentication from Header then I re-enter the authentication credentials again.
In my case enter after param and path generate error. Exact reason could be found in postman console.
In my case this happened because I added an extra blanckspace at the end of an environment variable deffinition. That extra space was being taken into account in the route when making a request.
Be careful with those extra blanck spaces.
I’m working on an widget for the fiware mashup. It needs to get data in json from a server. I’ve realized that with the MashupPlatform.http.makeRequest.
The problem is, the server sends xml back, if I don’t ask to get json. I don’t find any option in the widget api to to do it so. (like the curl option --header 'Accept: application/json')
As you have said, when you perform an HTTP request, you should add the Accept header to specify the response format. When you are using the MashUp Platform to make requests, you can specify the headers by adding the object "requestHeaders" in the options parameter. For example:
MashupPlatform.http.makeRequest("http://YOUR_SERVICE_URL/PATH", { "requestHeaders": {"Accept":"application/json"}});
You can check all the options that you can include in a HTTP request in the documentation: https://wirecloud.readthedocs.org/en/latest/widgetapi/widgetapi/#request-options-general-options
Best Regards
I am experimenting with libcurl for a multipart upload to s3. My initiate multipart request looks like this
POST /my_new_file.mbi?uploads HTTP/1.1 Accept: / Host:
test_bucket.s3.amazonaws.com Date: Thu, 01 May 2014 13:35:17 GMT
Authorization: AWS4-HMAC-SHA256
Credential=XXXXXXX/20140501/us-east-1/s3/aws4_request,SignedHeaders=host,Signature=1a3fd6195040494dd95507455a3b1eefef40346485e3fdafbe6cc136192365a2
I get the following response
The provided 'x-amz-content-sha256' header must be a valid SHA256.
s3 documentation says we do not need any other headers for Initiate multipart upload call(POST). Have tried with various combinations of signed empty content, but no luck.
What am I missing here? Any suggestions here will be very helpful.
Thanks
I haven't used version 4 auth, yet, for multipart uploads (my code uses v2), but I did find this:
x-amz-content-sha256
When using signature version 4 to authenticate request, this header provides a hash of the request payload. For more information see Authenticating Requests by Using the Authorization Header (Compute Checksum of the Entire Payload Prior to Transmission) - Signature Version 4. When uploading object in chunks, you set the value to STREAMING-AWS4-HMAC-SHA256-PAYLOAD to indicate that the signature covers only headers and that there is no payload. For more information, see Authenticating Requests Using HTTP Authorization Header (Chunked Upload).
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html
Obviously, chunked and multipart are not the same thing, but perhaps this value is also appropriate for a multipart upload request, or will generate a new and more helpful error message. The documentation seems unfortunately sparse in this case.
For Googlers who got this error:
Missing required header for this request: x-amz-content-sha256
While using awscli, what worked for me was setting the region correctly in the file ~/.aws/config (I'm using Ubuntu) to us-east-1. US only doesn't work nor does US Standard. The returned error doesn't really indicate that.
STREAMING-AWS4-HMAC-SHA256-PAYLOAD appears to no longer work. I was able to make it work by passing the SHA256 hash of the empty string, e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
I am attempting to build a c# module to connect to the Twitter streaming API using OAuth (now the only option). I have got to the point where my module will successfully access api urls using GET, but everything I do to try and make a POST request fails with a 401.
I have checked my signature is correct by using the OAuth Tool tab on the page for my Twitter App, and fixing the values for nonce and timestamp in my code. I have curl for Windows set up and can verify that it works with the sample curl script generated by the OAuth tool (by the way, this needs some correction of the quotes to make it work for curl in Windows Cmd. Get rid of single quotes on values that don't need them, use double quotes on anything that needs to be quoted, and on the Authorization header, use double quotes and escape double quotes within the header with a backslash).
I have even gone to the length of running curl in trace mode and outputting the bytes I send in the post body from my c# code and I can verify that they are the same.
I am trying to access 'https://stream.twitter.com/1.1/statuses/filter.json' using 'track=twitter' as the post body. The headers are:
Accept: */*
User-Agent: curl/7.21.7(amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8rzlib/1.2.5
Content-Type: application/x-www-form-urlencoded
Host: stream.twitter.com
Content-Length: 13
Connection: Keep-Alive
Authorization: OAuth <the oauth stuff>
I can't inspect the packets being sent to check on the wire that the requests are identical as they are of course SSL encoded.
Any ideas?
I eventually got this to work. Things that might help you if you have this kind of problem which I discovered:
I had a problem initially because I created a new nonce every time the bit of code was accessed. This meant the nonce which was used in generating the signature key was different from the one in the header. Obviously fail.
I then ran into the above problem. What it was is that I was adding the OAuth header to my request AFTER I sent the request body. For some reason it seems to send the request as soon as you write to the request stream for a POST.
It was very useful in finding 2. that I found out how to use Fiddler to trace web requests from code. Essentially all you need to do is add this to your web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
As soon as I tried to read the HTTPS request, Fiddler prompted me to install bits so it could decrypt the request, which I did and then I could see the exact request going down the wire. I could compare this with what cURL was doing using
-x 127.0.0.1:8888
option.
However I then ran into a problem with my request timing out. Which bizarrely enough was caused by the fact that Fiddler was proxying the response. Once I took the above out of my web.config again it all worked. Halleluja!
I would like to create a new Trello Card when a new User signs up for our webapplication.
To do that I requested a "read,write" Token (lets name it "myToken" ) for my user and I have my application key (lets name it "myKey").
Because I could not find any PHP-Wrapper I first used Fiddler to test the HTTP-Post request. Specifically I tried the following:
HTTP-POST
URL:
http://api.trello.com/1/cards
Request-Headers:
User-Agent: Fiddler
Host: api.trello.com
Content-Length: 177
Request Body:
key=myKey&token=myToken&name=newCardName&desc=newCarddescription&idList=myListId
However this doesnt work. I get back an HTML-Code, that shows a website which tells the user to login! What am I doing wrong?
Thanks #Daniel LeCheminant.
I made two mistakes:
1.) I used http instead of https
2.) I put the variables in the request body. Even though it is a post request, trello expects the variables in the url itself
This solution works for me:
https://api.trello.com/1/cards?key=myKey&token=myToken&name=newCardName&desc=newCarddescription&idList=myListId