[Apiman-user] APIMan return error 400 for header Access-Control-Request-Method

Renato Barros renalexster at gmail.com
Tue Dec 18 12:29:30 EST 2018

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 at 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 at 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 at 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 at 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 at 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 at 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-header-access-control-request-method>
>>>>>> .
>>>>>> Please, someone could help me?
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/0625298e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 92809 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/0625298e/attachment-0001.png 

More information about the Apiman-user mailing list