I'm making the request through a web app(POST) sending data via headers(JSON), so in the server side I need to read this data to execute a function...The JSON doesn't go "via the headers". In the headers there is a Content-Type specified and the actual JSON is send as data just under the headers.
Access-Control-Request-Method: GETThis seems like a GET method.
What were the sending headers you got in Angular?const headers = new HttpHeaders()
What code do you use in Angular for that AJAX call?this.http.get('http://192.168.0.12:8080/lol', {headers}).subscribe((res) => {
I wonder if Angular filters out some of the headers because this is a GET, not a POST.QuoteWhat code do you use in Angular for that AJAX call?this.http.get('http://192.168.0.12:8080/lol', {headers}).subscribe((res) => {
console.log(res);
});
Did you try setting the headers with the following?
let headers = new HttpHeaders();
headers = headers.append('Filter', 'Hello World');
The weird thing is (as you said) the header-title are there but no data!Yes, but those header-titles are not really headers. They are appended to Access-Control-Request-Headers. So something puts those headers into that single Access-Control-Request-Headers.
The preflight is being triggered by your Content-Type of application/json. The simplest way to prevent this is to set the Content-Type to be text/plain in your case. application/x-www-form-urlencoded & multipart/form-data Content-Types are also acceptable, but you'll of course need to format your request payload appropriately.https://stackoverflow.com/questions/22968406/how-to-skip-the-options-preflight-request-in-angularjs
If you are still seeing a preflight after making this change, then Angular may be adding an X-header to the request as well.
Unlike “simple requests” (discussed above), "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.
Another thing that I found was that TTCPBlockSocket don't accept any header attribute!What do you mean?
What do you mean?I meant that the component doesn't work with some header attributes, like I tried execute a post passing "Access-Control-Allow-Origin","*", with that the header looks like as I said previously... So, without that header it works fine! I just had to change the "Content-Type" to "text/plain";
But TTCPBlockSocket isn't a HTTP-component. So you are dealing with raw data. It accepts all that data.Do you know any HTTP component which I could build a webservice or anything like that? I mean "easier" to work with HTTP requests?
any HTTP component which I could build a webservice or anything like that? I mean "easier" to work with HTTP requests?
How does a http message actually looks like?
[...]
And this is what you receive. Everything else is a question of formatting. And the JSON would be the message, or inside <html><head/><body>JSON</body></html> tags, depending.
Well, it's my first experience with this kind of function using Laz/FPC, and that was the way that I found to solve the problem! Probably there is an easiest way to do it...Well, the problem lied on the client side. Angular (or the browser) first sends an OPTION request before sending the real GET or POST. That's because you added the custom headers. If you didn't, or you change the content-type, the GET or POST is sent directly. That's why it would also be an option to send an OK back to the client and wait for the actual GET or POST. It's really annoying that extra OPTION request is sent, but I don't know how to disable it easily, other than sending text/plain as content-type.
Do you know any HTTP component which I could build a webservice or anything like that? I mean "easier" to work with HTTP requests?Synapse does not have such HTTP-server component. Indy does. But I'm not sure if Indy takes these pre-flight OPTION requests into account.
F.Y.I. here is some information how you would respond to an OPTION request:I'll read it!
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request