Hello Apigee Support team and fellow devs with questions and answers,
thanks for any support on this. this is more a confirmation than a question. when you do a raise error on apigee with FaultResponse/Set as seen here http://apigee.com/docs/ja/api-services/reference/raise-fault-policy you override the entire headers killing in the process the cors headers.
is there a way to maintain the cors headers on the raise error? or you have to manually add them?
Marco
create a javascript policy where you store the headers in a different variable, the set them in the RaiseError policy.
The script will look something like...
context.setVariable("myVariable", context.getVariable("request.header.{name}"));
Then in the RaiseFault use {myVariable} to place the value in the header.
Please provide examples of your source code if you need a more accurate answer.
Related
I figured this was going to be a straight forward exercise via a ResourceRequestHandler and overriding the OnResourceResponse.
But the implementation throws NotSupportedException: IResponse is read-only and cannot be modified. Check IResponse.IsReadOnly to guard against this exception, if I try to manipulate the Headers or even if I try to call SetHeaderByName on the IResponse
I found this Cef issue, so I figure it is a Cef limitation. Is this correct ?
I also had a look at if it might be possible to implement a custom IResourceHandler and manipulate the response headers via GetResponseHeadersmethod, but any discussion of this Interface online seems to refer around handling requests, not responses.
Can it be done with an IResourceHandler ? Are there some examples ?
Does anyone know how to call the Clockify API in Power Bi?
I just cant seem to get it right. I have read through the Clockify API documentation and the I cant transpose the code in Power Bi.
let
Source = Json.Document(Web.Contents("https://api.clockify.me/api/",
[Headers=[Accept="application/json", #"x-api-key"="xxxxxxxxxx"]])),
messages = Source[messages]
in
Source
So I don't know PBI but one issue I think I see with your call is the "Headers" should include a "Content-Type" - "application/json" header. You don't need the "Accept" header. And you might have shortened it, but your endpoint URL needs an actual endpoint - https://api.clockify.me/api/ won't return anything. Instead you should test trying to get the workspace information, for example, which I think would look something like this:
let
Source = Json.Document(Web.Contents("https://api.clockify.me/api/workspaces/",
[Headers=[#"x-api-key"="xxxxxxxxxx"]])),
messages = Source[messages]
in
Source
This one doesn't need the content-type header because it's just a GET request. I don't know how PBI creates different types of requests, but certain requests need to be GET requests, while others need to be POST/PUT/DELETE/etc.
did you get around this? there is no support on official website of clockify as for now, but it seems that it could be done by the clockify API but same as your code it does not run.
We've got a client that would like to get a response from our server that would look something like that:
http://www.clientDomain.com/tmp?first=a&second=b&link=$$http://www.otherDomain.com/tmp?third=c&forth=d$$
The client doesn't want the link parameter to be encoded.
As far as I'm aware, this is an illegal parameter, that may seems like one is trying to confuse a web server or a router, yet I could not find any documentation to support that. I didn't find any relevant info in the http protocol documentations.
Is that really an illegal parameter? Can you please refer me to a relevant documentation?
Thanks a lot.
See the URL Encoding section here: https://en.wikipedia.org/wiki/Query_string
What is the use of X-Mx-ReqToken HTTP header? Almost all tutorials on enabling CORS in nginx whitelist the X-Mx-ReqToken header. But I can't find any information on the purpose of the header.
X-Mx-ReqToken is a header used to supply a profiler key for Mendix Runtime:
Member Data Documentation
final String com.mendix.systemwideinterfaces.core.IProfiler.PROFILER_KEY = "X-Mx-ReqToken" [static]
Basically, this is just a case of copying & pasting the same snippet over and over again until it made it to every nginx CORS tutorial out there. But unless you actually use said profiler, it's safe to omit.
Is there any way to determine if a POST endpoint exists without actually sending a POST request?
For GET endpoints, it's not problem to check for 404s, but I'd like to check POST endpoints without triggering whatever action resides on the remote url.
Sending an OPTIONS request may work
It may not be implemented widely but the standard way to do this is via the OPTIONS verb.
WARNING: This should be idempotent but a non-compliant server may do very bad things
OPTIONS
Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
More information here
This is not possible by definition.
The URL that you're posting to could be run by anything, and there is no requirement that the server behave consistently.
The best you could do is to send a GET and see what happens; however, this will result in both false positives and false negatives.
You could send a HEAD request, if the server you are calling support it - the response will typically be way smaller than a GET.
Does endpoint = script? It was a little confusing.
I would first point out, why would you be POSTing somewhere if it doesn't exist? It seems a little silly?
Anyway, if there is really some element of uncertainty with your POST URL, you can use cURL, then set the header option in the cURL response. I would suggest that if you do this that you save all validated POSTs if its likely that the POST url would be used again.
You can send your entire POST at the same time as doing the CURL then check to see if its errored out.
I think you probably answered this question yourself in your tags of your question with cURL.