How to configure Postman to send Content-Type: application/json header on every request
I found the following solution in a blogpost post which consists of adding a pre-request script to my collections/folder/request.
pm.request.headers.add({
key: "Accept",
value: "application/json"
});
Related
It's possible to change the expiration time response variable huawei (expires_in) when we obtain a new token for send push kit notification?, or what would be the best way to renew this token on my server
by default the variable (expires_in) is set in 3600 seconds i like to change this number to more time.
the documentation don't show nothing for change this variable, its only show:
Send a POST request. Example:
POST /oauth2/v3/token HTTP/1.1
Host: oauth-login.cloud.huawei.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=<Client ID>&client_secret=<Client secret>
Response message:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
{
"access_token": "<Returned access token>",
"expires_in": 3600,
"token_type": "Bearer"
}
response vars descriptions
change the expiration time response variable (expires_in)
Did you try this?:
grant_type=client_credentials&time_out=4500&client_id=&client_secret=
I have an application that has been successfully using HTTP batch requests to insert, edit, and delete events via the Google Calendar API. In the last couple of days, the individual requests within the batches have started returning 404 errors (although the batch itself gets a 200 success response). Making those same requests as individual requests using the same authorization header is still working.
I'm pretty sure that this isn't related to the forthcoming shutdown of Google's global HTTP batch endpoints because we're using https://www.googleapis.com/batch/calendar/v3 as our endpoint.
Here's an example of what I'm trying to do:
https://www.googleapis.com/batch/calendar/v3
Authorization: Bearer your_auth_token
Content-Type: multipart/mixed; boundary=batch_google_calendar
--batch_google_calendar
Content-Type: application/http
Content-ID: <item-0-batchevent#example.com>
POST calendar/v3/calendars/your_calendar_id#group.calendar.google.com/events
Content-Type: application/json
{"summary":"batch API test","start":{"date":"2020-07-31"},"end":{"date":"2020-07-31"}}
--batch_google_calendar--
And the response is:
--batch_3J6sfuPtVQbjZLcpUe06245gKlO31YnC
Content-Type: application/http
Content-ID: <response-item-0-batchevent#example.com>
HTTP/1.1 404 Not Found
Vary: Origin
Vary: X-Origin
Vary: Referer
Content-Type: application/json; charset=UTF-8
[{
"error": {
"code": 404,
"message": "URL path: /v3/calendars/your_calendar_id#group.calendar.google.com/events could not be resolved. Maybe there is an error parsing the batch item.",
"status": "NOT_FOUND"
}
}
]
--batch_3J6sfuPtVQbjZLcpUe06245gKlO31YnC--
And here's an example of an individual request that's working:
https://www.googleapis.com/calendar/v3/calendars/your_calendar_id#group.calendar.google.com/events
Authorization: Bearer your_auth_token
Content-Type: application/json
{"summary":"API test","start":{"date":"2020-07-31"},"end":{"date":"2020-07-31"}}
Why might the individual request be succeeding but the batch request fail?
Google gave a helpful reply via their issue tracker: there was an error in the way that batch entry paths were specific in my application. This had worked without errors until last week, so I think something must have changed at their end to make it less tolerant of mistakes.
The error we had made was omitting the leading slash in the path in each batch entry. Here's what we were doing:
POST calendar/v3/calendars/your_calendar_id#group.calendar.google.com/events
And here's what we should have been doing:
POST /calendar/v3/calendars/your_calendar_id#group.calendar.google.com/events
I hope that this might be helpful to anyone else who ever finds themselves in a similar situation!
I want to use HERE maps autocomplete in my project.
But when a i send request like the one in documentation
this.axios.get('http://autocomplete.geocoder.api.here.com/6.2/suggest.json
?app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
&query=Pariser+1+Berl
&beginHighlight=<b>
&endHighlight=</b>'
)
.then(response => {
console.log(response)
})
.catch(error => {
console.log(error)
})
i get an error
OPTIONS http://autocomplete.geocoder.api.here.com/6.2/suggest.json?{...} 405
Access to XMLHttpRequest at 'http://autocomplete.geocoder.api.here.com/6.2/suggest.json?{...}' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
In Chrome developer console in network panel i check this
Provisional headers are shown
Access-Control-Request-Headers: x-auth-token, content-type
Access-Control-Request-Method: GET
I set content-type in request headers to application/json and Provisional headers changed
to Access-Control-Request-Headers: x-auth-token
Access-Control-Request-Method: GET
So if i understand right, i should set x-auth-token header. But where can i take this token?
Or may be this problem has another reason?
There's nothing about such problems in documentaion.
The problem was simple and a bit stupid.
When user authenticated in my app I added default header to axios
axios.defaults.headers.common['X-Auth-Token'] = token
so this header was sended to all requests.
But HERE-map API doesn't want this header in requests and this was the cause of the problem.
The solution was to remove this header from requests to HERE-map API.
For those who have defined by default the header :
'Content-Type': 'application/json'
You must deactivate it, there should not be any HttpHeaders on the call request to Here API services.
temporary install Allow-Control-Allow-Origin google chrome plugin .. installed then you can show top right side click on that and switch the button then refresh then again call your api and get the response.
I am using cljs-http and I am not able add custom headers into http request. Adding code snippet with request creation:
arg {:basic-auth auth
:headers {
"Access-Control-Allow-Origin" " *"
"Access-Control-Allow-Headers" "Origin, X-Custom-Header, Content-Type, Accept"
"X-Custom-Header" "Custom header"}
resp (csp/<! (cljs-http/get url arg))
Output in chrome console:
XMLHttpRequest cannot load url. Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers.
Could you please suggest me how to do it ?
The problem was related not to clojurescript, but to server side.
The CORS headers were not configured.
While handling requests, server should attach Access-Control-Allow-Origin, Access-Control-Request-Method headers to response that's permit performing requests for frontend (cljs).
I have the following situation:
The browser does a POST with a Json payload to my server endpoint
My server processes the data and then issues a redirect to a new location
The browser does the redirect, but it does it with the same headers as the original post which mean it arrives at my endpint such that my endpoint
thinks it is a json request.
-> I want the redirect to arrive at my server as a standard text/html request.
Is it possible to control the headers that the redirect uses so that the Get request arrives with text/html Accept headers?
Here are some snippets from fiddler to highlight what I am talking about:
Initial POST, json payload:
POST /App/Client/Index HTTP/1.1
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
The response:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
The subsequest GET request from the Redirect:
GET /App/Client/SingleEntity?entityId=f859a6ca-dbcf-49cf-8de0-3888b7011815 HTTP/1.1
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
I had a similar requirement. My solution was to not send a redirect, but a "200 OK" with the following JSON:
{"url": "http://example.com/redirect/to/some/resource"}
The client used the URL and redirected via Javascript, i.e. location.href = data.url. It might not be the answer you're looking for but it solves your problem...
See also: How to manage a redirect request after a jQuery Ajax call