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

Marc Savy marc.savy at redhat.com
Tue Dec 18 12:04:39 EST 2018


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/e2b17da6/attachment.html 


More information about the Apiman-user mailing list