I am trying to retrieve all the statements from a named graph (the name is a URI) within a repository using the Graph Store HTTP Protocol. I am using version 8.10 GraphDB installation on Windows 10.
The installation reports the API's availability at:
/repositories/{repositoryID}/rdf-graphs/{graph}
However, replacing {graph} with the URI leats to a report of No Handler Found error or a noslash error (if the URI is encoded).
I've tried unencoded URIs and encoded URIs. The referenced specification SPARQL 1.1 Graph Store HTTP Protocol suggests ?graph={graph} may be required but this also fails.
Some examples:
Unencoded
11:14:50.901 [http-nio-7200-exec-2] WARN o.s.w.s.m.s.DefaultHandlerExceptionResolver - Resolved [org.springframework.web.servlet.NoHandlerFoundException: No handler found for GET /repositories/foodandwine/rdf-graphs/http://www.w3.org/TR/2003/PR-owl-guide-20031209/food]
Replacing ":" with %2e
11:14:59.583 [http-nio-7200-exec-10] WARN o.s.web.servlet.PageNotFound - No handler found for GET /repositories/foodandwine/rdf-graphs/http%3e//www.w3.org/TR/2003/PR-owl-guide-20031209/food
Replacing ":" with %2e and "/" with %2f
Message Invalid URI: noSlash
Description The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
I am sure I've missed something very simple but a steer in the right direction would be greatly appreciated.
As Damyan said, use a URL like this:
curl -X GET --header 'Accept: application/rdf+xml' http://localhost:7200/repositories/test/rdf-graphs/service?graph=http%3A%2F%2Fbase.org%2Ftest
Reposting his comment as answer, so this question doesn't appear again in [graphdb] answers:0
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 am trying to carry out a test as like it explained here:
JMeter Alter HTTP Headers During Test.
Quote from above :
I'm attempting to test an HTTP service with JMeter. The HTTP service requires authentication through a simple bearer token mechanism. I'm trying to proceed as follows:
POST authentication request Store token as a variable
Set Authorization HTTP header to stored variable
Request protected resource(s)
Evaluate performance
When the POST occurs, I am not able to capture the bearer token. Its a header.
I tried the solution provided by Dmitri on that issue Or as Bennet tried with RegEx Extractor and HTTPs Manager.
I think I am doing something silly not to able to extract the token. Any thoughts how to extract the token?
Most likely your Regular Expression Extractor configuration is not correct, by default it:
uses response body as a source therefore you need to switch it to look into response headers (red rectangle)
looks up in main sample only, if your header is set after redirect it won't be processed (amber rectangle)
Example configuration:
You can double check ${bearer} variable value using Debug Sampler and View Results Tree listener combination.
I'm attempting to authenticate my application using Spotify's web API Client Credentials Authorization flow, but despite the seemingly simple task, every response I've gotten has returned a 500 - Internal Server Error.
I've attempted many times in both cURL and within my application (Android) to no avail. Following the guides here: https://developer.spotify.com/web-api/authorization-guide/#client_credentials_flow
I've set up my cURL as such
curl -XPOST -H 'Authorization: Basic ODZiMDJ...MWI=' -d 'grant_type=client_credentials' 'https://accounts.spotify.com/api/token'
The request is structured with identical headers, body, and URL in the code as well, but I have yet to receive any valid responses.
Another question posted here gives a seemingly identical request, aside from the optional "Scope" parameter.
My apologies if this seems like a vague question - I'm not sure what else to try, but I'd be more than happy to provide any additional details. Any help is appreciated.
code and redirect_uri body parameters are required according to documentation
I'm trying to use the new Heroku api to stream the logs of my application using curl:
Here is what is said in the doc (https://devcenter.heroku.com/articles/platform-api-reference#app)
Streaming is performed by doing an HTTP GET method on the provided logplex url and retrieving log lines utilizing chunked encoding.
So first I retrieve the logplex url:
curl -X POST https://api.heroku.com/apps/my-app/log-sessions \
-H "Accept: application/vnd.heroku+json; version=3" \
-H "Authorization:XXX" -v
Then I get something like this in the response:
"logplex_url":"https://logplex.heroku.com/sessions/abcdef-079b-4264-a83c-031feb31bfc2?srv=132456798"
So I make another curl call:
curl -X GET "https://logplex.heroku.com/sessions/abcdef-8a7e-442f-a164-4c64e845b62d?srv=123456798" -H "Transfer-Encoding: chunked"
I got a persistent connection but nothing comes...
If I don't specify the Transfer-Encoding header, I get the logs, but the connection close.
Is it really possible to stream the logs, like it's specified in the reference ?
It is possible, unfortunately I was mistaken in writing it and it is not chunked encoding as I believed. We do use this interface in the CLI and in log2viz, but it is unfortunately not standard http per se.
Basically you should do a normal HTTP request and read back the HTTP response headers. Given the headers returned you would then normally read from the socket until you got a zero length read, at which point you can assume you are done and finish up. In the logplex case we are reticent to block (perhaps indefinitely) so we go ahead and return an empty read. Then we just expect that when you are done you can simply close the socket.
Unfortunately I was unable to figure out how to do this with cURL. But I can point to the examples in our open source where we tackle this, and hopefully that will help.
toolbelt - https://github.com/heroku/heroku/blob/master/lib/heroku/client.rb#L482
log2viz - https://github.com/heroku/log2viz/blob/master/app.rb#L153
Hopefully that helps clarify the current situation at least, I'll try to update the docs to reflect this. Thanks for the detailed report and let me know if you have additional questions I can help with.
when trying to read this kind of url
URL: http://v4.lscache2.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id,expire,ip,ipbits,itag,algorithm,burst,factor,oc:U0dWSlhTVF9FSkNNNl9QTVhJ&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1275886800&key=yt1&signature=89195E808CB3FBBC7BDE7298A1DC0613D7987F00.D3064112E8F479C523F8DF4FBFDF392CE48167C2&factor=1.25&id=34e01ad39b34b5c9&
I get this error
read/binary url
connecting to: v4.lscache2.c.youtube.com
** User Error: Error. Target url: http://v4.lscache2.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id,expire,ip,ipbits,
itag,algorithm...
** Near: read/binary url
In Rebol 3 you get:
** Access error: protocol error: "Server error: HTTP/1.1 403 Forbidden"
The message you're getting is Rebol 2's not-so-eloquent way of saying that. (You can also enter it in Firebug and see that using this raw URL does not work.)
I'd imagine that YouTube will only let you get the stream if the requesting HTTP header matches a certain pattern. Among potential things it might look for is a cookie specifically crafted for your session and designed to expire after a certain time.
As far as I understand it YouTube is not too keen on third party downloads of video data. They used to have a get_video API but appear to have disabled it. So you'll either have to fake up a cookie and make them think you're one of their players, or find a service which is friendlier to this sort of application.