Thanks for your reply Marc,
About the OPTIONS request: It results from the preflight request, so it's
not the real request. My frontend is attempting to do a POST request.
However, before this, a preflight is sent to the server automatically. The
matter is *The Preflight Request Fails*
[image: image.png]
The POST request works.
My question is: Is there some problem with my CORS Policy? Should I disable
(turn False) Terminate on Cors Error? Or It's the result of some CORS
plugin problem?
On Tue, 18 Dec 2018 at 14:04, Marc Savy <marc.savy(a)redhat.com> wrote:
Just to confirm: the purpose of the CORS plugin is to provide a CORS
frontend to a service which does not currently have CORS. It is not to
bypass CORS on a backend service that *already* has CORS.
I believe you may be misunderstanding how the CORS protocol works.
From my recollection, if you are doing a non-simple request (such as
yours), then you must execute a preflight request first (which is a special
type of OPTIONS request --
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests
).
The browser first executes the preflight request, THEN it separately and
subsequently executes the real request. So, if you were attempting to
execute an OPTIONS request then you would execute 2 separate calls. This is
done on your behalf transparently by the browser.
The 'real' call is approved by virtue of the preflight request, and does
not require the CORS headers you're including (which make it look like a
preflight request).
Please see:
https://mdn.mozillademos.org/files/16401/preflight_.png
If you are doing a *simple* request, as per the CORS specification, then
no preflight is required and you embed the headers in the 'real' request as
your samples show.
Does this resolve your issue?
On Tue, 18 Dec 2018 at 12:59, Renato Barros <renalexster(a)gmail.com> wrote:
> Hello Marc,
>
> I don't think the problem is associated with
> *Access-Control-Allow-Origin*. Below there are two requests using
> Restlet Client, the first one works without the *Header
> Access-Controle-Request-Method*, the second only adding this Header gets
> fail.
>
>
> [image: image.png]
>
> On Tue, 18 Dec 2018 at 09:40, Marc Savy <marc.savy(a)redhat.com> wrote:
>
>> I think your issue might be the way that you're formulating your request.
>>
>> In order to issue a valid CORS request, you must set your origin header.
>> You should probably try that first.
>>
>>
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin
>>
>> e.g. curl ... -H "Origin: mymachine.local"
>>
>> When using a browser, this is usually issued on your behalf. But, if
>> you're using curl, it won't be.
>>
>>
>> On Tue, 18 Dec 2018 at 12:35, Renato Barros <renalexster(a)gmail.com>
>> wrote:
>>
>>> Hi Marc,
>>>
>>> I've just updated the image with details. The
>>> Access-Control-Allow-Origin already had "*" as value.
>>>
>>> [image: image.png]
>>>
>>> On Tue, 18 Dec 2018 at 05:50, Marc Savy <marc.savy(a)redhat.com> wrote:
>>>
>>>> I'm not sure why your browser isn't rendering it, but there
should be
>>>> a list in the Access-Control-Allow-Origin section that would allow you
to
>>>> add an entry such as "*" or "foo.com".
>>>>
>>>> What is your setup?
>>>>
>>>> On Mon, 17 Dec 2018 at 19:10, Renato Barros
<renalexster(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'm getting an error with *Access-Control-Request-Method* Header
in
>>>>> my APIs.
>>>>>
>>>>> I posted details in StackOverflow
>>>>>
<
https://stackoverflow.com/questions/53821510/apiman-return-error-400-for-...
>>>>> .
>>>>>
>>>>> Please, someone could help me?
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>