1:05 p.m.
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?
2:49 a.m.
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
6:34 a.m.
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
>
6:40 a.m.
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
>>
>
6:58 a.m.
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
>>>
>>
11:04 a.m.
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
>>>>
>>>
11:29 a.m.
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
>>>>>
>>>>
11:54 a.m.
Sorry Marc,
I misunderstood the concept of CORS and the plugin. My APIs are already
prepared to use CORS requests. So that, I even don't need to create a CORS
Policy in the APIMan.
On Tue, 18 Dec 2018 at 14:29, Renato Barros <renalexster(a)gmail.com> wrote:
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
>>>>>>
>>>>>
2:12 p.m.
No problem, glad we cleared it up!
On Tue, 18 Dec 2018 at 17:55, Renato Barros <renalexster(a)gmail.com> wrote:
Sorry Marc,
I misunderstood the concept of CORS and the plugin. My APIs are already
prepared to use CORS requests. So that, I even don't need to create a CORS
Policy in the APIMan.
On Tue, 18 Dec 2018 at 14:29, Renato Barros <renalexster(a)gmail.com> wrote:
> 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
>>>>>>>
>>>>>>
6:05 a.m.
New subject: APIMan return error 400 for header Access-Control-Request-Method
My two cent on below… Sorry if it spams your inbox.
The CORS Policy Preflight request, as per specification has to be a GET request and so if
we use APIMan CORS Policy, we have to send the “apiKey” in get Request. We faced this
issue and so sharing our experience (Preflight request was not sending apiKey as we
configured in Header).
Agree, sending “apiKey” through GET is not recommended, but this is CORS preflight spec
restriction and we have to leave with it. Any thoughts on how APIMan can help avoid that ?
(allow preflight without apiKey on CORS request ?).
From: apiman-user-bounces(a)lists.jboss.org [mailto:apiman-user-bounces@lists.jboss.org] On
Behalf Of Marc Savy
Sent: Wednesday, December 19, 2018 01:42
To: Renato Barros
Cc: apiman-user(a)lists.jboss.org
Subject: Re: [Apiman-user] APIMan return error 400 for header
Access-Control-Request-Method
No problem, glad we cleared it up!
On Tue, 18 Dec 2018 at 17:55, Renato Barros
<renalexster@gmail.com<mailto:renalexster@gmail.com>> wrote:
Sorry Marc,
I misunderstood the concept of CORS and the plugin. My APIs are already prepared to use
CORS requests. So that, I even don't need to create a CORS Policy in the APIMan.
On Tue, 18 Dec 2018 at 14:29, Renato Barros
<renalexster@gmail.com<mailto:renalexster@gmail.com>> wrote:
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
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@redhat.com<mailto:marc.savy@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@gmail.com<mailto:renalexster@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.
On Tue, 18 Dec 2018 at 09:40, Marc Savy
<marc.savy@redhat.com<mailto:marc.savy@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@gmail.com<mailto:renalexster@gmail.com>> wrote:
Hi Marc,
I've just updated the image with details. The Access-Control-Allow-Origin already had
"*" as value.
On Tue, 18 Dec 2018 at 05:50, Marc Savy
<marc.savy@redhat.com<mailto:marc.savy@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<http://foo.com>".
What is your setup?
On Mon, 17 Dec 2018 at 19:10, Renato Barros
<renalexster@gmail.com<mailto:renalexster@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-retu...;.
Please, someone could help me?
_______________________________________________
Apiman-user mailing list
Apiman-user@lists.jboss.org<mailto:Apiman-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user
Accept the Challenge. Go Paperless
1980
days inactive
1982
days old
9 comments
3 participants
participants (3)
-
Ashish Patel -
Marc Savy -
Renato Barros