When sending a POST request to a web server, can you specify the Accept header parameter alongside Content-type? As in, I am sending some JSON, so I'll specify that in Content-type, but since I expect a response from the server (perhaps the object that will be added to the database), I would specify that in the Accept parameter?
When sending a POST request to a web server, can you specify the Accept header parameter alongside Content-type?
Yes. Accept is what you will accept in the response. Content-Type is what you are sending in the request. They are entirely independent.
Related
By correlate requests in Azure APIM and Application Insight with W3C distributed tracing Azure, if the client dose not send the traceparent header, seems APIM would checks the incoming request and if no traceparent, the APIM would generate and set from the request goes to backend.
In this case, we would like to return the traceparent information from the frontend response header so the consumer who inoke the API would get it, they could report API issue with this traceparent id so we can better trace/diagnose it with service log.
The question is how to get the APIM generated traceparent from inbound/outbound policy, please suggest a approach, thanks !
The traceparent HTTP header field identifies the incoming request in a tracing system. The traceparent describes the position of the incoming request in its trace graph in a portable, fixed-length format.
If the traceparent HTTP header is not available then, you can set it by using the set-header policy of API Management policies. The set-header policy is used to assigns a value to an existing response and/or request header or adds a new response and/or request header.
When placed in an inbound pipeline, this policy sets the HTTP headers for the request being passed to the target service. When placed in an outbound pipeline, this policy sets the HTTP headers for the response being sent to the gateway’s client.
The below snippet shows how you can set a new correlation context header if none is available.
<set-header name="traceparent" exists-action="skip">
<value>#($"00-{context.RequestId.ToString("N")}-0000000000000000-01")</value>
</set-header>
With the context.RequestId.ToString("N") you get the internally correlated id of the request and format it without dashes. But don't forget to set the correlation format in the Settings tab to W3C.
And with this you will get the traceparent in the header section of your request.
I would suggest you to read this W3C document on traceparent headers and Correlation headers using W3C TraceContext for more information.
I'm using Postman with the Interceptor extension to perform a POST request.
My request contains an Origin header to be able to avoid CORS errors. The Content-Type is application/x-www-form-urlencoded and I receive json, so I had to add the Accept header with value application/json.
The API I call wants me to add the Referer header as well, so I do that. When I send the request, the Accept header is not in the raw request. When I remove the Referer header, the Accept header shows up in the raw request.
Is this a bug in Postman/Interceptor or am I doing something against 'the rules' of sending http requests?
I need to send POST request and get json from it.
Create Http Context emopstest.pdc.org http
Set Request Header Content-Type application/x-www-form-urlencoded
Set Request Header Authorization Basic bG9naW46cGFzcw==
${dict}= Create Dictionary app_ids=18 where=ROWNUM<=2000
${value}= Stringify Json ${dict}
Set Request Body ${value}
HttpLibrary.HTTP.POST /auth_srv/services/auth/1/json/get_hazards
Show Response Body In Browser
Response Status Code Should Equal 200
${result_text}= Get Response Body
${result_json}= Parse Json ${result_text}
But this code returns to me 404...
What is wrong?
The 404 means that the server couldn't find the resource you requested. Usually that means the URL was wrong. Depending on how the server is configured, it could also mean that your authorization is wrong (ie: some applications will give a 404 in the case of bad authentication, so that an attacker isn't given a clue that the credentials are incorrect)
The server logs should have information that will help you track down whether you have an incorrect URL or that the server has a bug.
I am attempting to retrieve some data from a 3rd party domain. When I enter the request url. I am able to see the data I requested. But when I attempt to make a call using ajax (to a different domain), it returns the error message. Why am I not able to retrieve the data? Might it have something to do with cross-domain policy and not using jsonp? Here is my code:
<script>
$(document).ready(function() {
$.ajax ({
type: 'GET',
url: 'https://crm.zoho.com/crm/private/json/Potentials/searchRecords?authtoken=xxx&scope=crmapi&criteria=(((Potential%20Email:test2#email.com))&selectColumns=Potentials(Potential%20Name)&fromIndex=1&toIndex=1',
dataType: 'json',
success: function(test) {
alert(JSON.stringify(test));
},
error: function(test) {
alert(JSON.stringify(test));
}
});
});
</script>
Because the request that you has send is blocked by the browser. When you perform a request using an object XmlHttpRequest and obviously javascript, the browser applied cross-domain policy, defined in WC3, and thus verify in url the origin and target domain (protocol, host and port), if those elements are in different domain (i.e. host and port), then the request never comes out from browser (a.k.a User Agent). You can use jsonp to "break" or "jump" this policy, simply is a tag "script" with a resource (src) defined in a different domain using a parameter called "jsonCallback=?" added in query string, who really receives the data in format json. This is more ugly and have a security risk, therefore never be used.
The other method is to use and enable a "technique" (is more than that) known like "CORS" (Cross Origin Request Sharing), where the client (browser) and server (resource at different domain), send, exchange and negotiate an Http Headers to secure that who send and who received are authorized to exchange information. The basics steps to realize CORS is:
Explicity define in client (ajax-jquery) that CORS will be used in request, specifying CrossDomain:true. This will enable HTTP Headers defined in CORS
Specify in the HTTP Server, a HTTP Header indicating the Domain Source that have permissions to call a resource hosted in server. The most general header can be defined like: Access-Control-Allow-Origin , with value asigned a domain, like "*" (all domain authorized) (Access-Control-Allow-Origin, *)
In some Browsers, sometimes they send a http header request called "preflight request", is like a discover via to know if the server is prepared to recieve cross-origin request. This Http Header contains a "Method HTTP" value or "Verb HTTP" (like PUT,POST,GET,DELETE) assigned to "OPTIONS", then the server must be configured too to recieve HTTP Headers with Method "OPTIONS", and therefore allow methods http like PUT, DELETE,POST or GET. In generals terms the server must have this headers when in the request had a method HTTP "OPTIONS":
Access-Control-Allow-Methods , "POST, PUT, DELETE, GET, OPTIONS"
Access-Control-Allow-Headers, ", "Content-Type, Accept"
Finally, the client (ajax) will recieve the data from the server.
This sounds a little confusing and the steps are few, sorry that not put a code like examples, but, really CORS is not hard to understand.
I hope this will help.
References from Mozilla:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
This show what is CORS and you can use in configuration server:
http://enable-cors.org/
I saw there are several related posts, but none really answered my questions.
To be specific, let's say there are some middle layers in front of the request handlers (e.g. web server, Spring framework, Jersey framework, etc). The request handler explicitly announced that it expects a JSON request.
Question 1 - if the client sends a valid JSON request, but set the content-type to be text/plain, is it valid situation for the middle layers NOT to deliver the request to the request handler because of the content-type?
Question 2 - if the client sends a valid JSON request and using content-type application/json, and the request handler announces that it will parse the JSON request by itself. Can I assume some real world implementations of the middle layers will still verify the request before passing it to the request handler? (in other words - is it valid to assume that application/json may cause performance loss?)
All application/json content is also valid text/plain, so I don't see how a middle layer validation could catch that. It doesn't make sense for it to reject the request, unless it knows the request semantics which is supposed to be the responsibility of the request handler. The opposite case would make sense, with a failure when sending plain text payload that's an invalid JSON document with application/json.
The middle layer may validate if the payload with application/json is valid, but to worry about performance loss at this point is pointless. If after profiling your application you realize that this validation is a bottleneck, then it's valid to worry about it.