Facing issue with CORS - only OPTIONS call is sent

[#1]

I have a proxy in which CORS is added as below in the Preflight response,

    <FaultResponse>
        <Set>
            <Headers>
                <Header name="Access-Control-Allow-Origin">{request.header.origin}</Header>
                <Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, Authorization, X-AMEX-API-KEY</Header>
                <Header name="Access-Control-Max-Age">362880000</Header>
                <Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header>
                <Header name="Access-Control-Allow-Credentials">true</Header>
            </Headers>
            <Payload contentType="text/plain"/>
            <StatusCode>200</StatusCode>
        </Set>
    </FaultResponse>

This particular proxy receives request for PUT http verb.

But I am facing a strange error that when request is triggered,only OPTIONS is coming in trace.Also,I could see original request with PUT verb not getting triggered at all.

What could be the issue which is stopping PUT request?Kindly let me know.

[gnanasekaran · Accepted solution]

check your browser's javascript console...

It's possible the PUT call did not happen because there is a problem with the CORS preflight, which is the OPTIONS call. The browser sends this out "to check" if it can make the PUT call.

The browser console might have clues on what's missing in the preflight. Especially Google Chrome will note why a rejection has occurred. Sometimes Firefox/Firebug does not provide good clues.

[gnanasekaran · Accepted solution]

check your browser's javascript console...

It's possible the PUT call did not happen because there is a problem with the CORS preflight, which is the OPTIONS call. The browser sends this out "to check" if it can make the PUT call.

The browser console might have clues on what's missing in the preflight. Especially Google Chrome will note why a rejection has occurred. Sometimes Firefox/Firebug does not provide good clues.

[DChiesa]

to add to Mukundha's comment, The preflight might fail if the browser is sending a header that is not in the list of Allow-Headers in your CORS RaiseFault.

[#5]

@Mukundha Madhavan

@Dino

@Sanjay Kammili

Thanks for hint.I tried to verify through Javascript console and found one extra header passed.I added it in Allow headers.

Now when I am hitting ,I could see PUT/GET request passed after Options.I could see this request passing all the policies but when it hits Target ,it throws either 404 or 500 errors.

The javascript console says,

XMLHttpRequest cannot load https://apigeehost.com/test/detail?id=12. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://testportal.com' is therefore not allowed access. The response had HTTP status code 500.

But I have added all the CORS related implementation for Preflight and TargetEndpoint-Postflow-Response.

What is still missing ?

[#6]

Also one more observation while I tried is,only for the first hit OPTIONS and PUT shown in trace.For the next hits,only PUT is shown in trace and OPTIONS not shown.

[DChiesa]

Yes, that's how CORS works in browsers. The browser runs the pre-flight and remembers the result. No pre-flight the 2nd time around, if it is not necessary.

[theapigeek]

I had the same problem yesterday, but I was able to debug and fixed as suggested in documentation and help from our community members answers.

I added fiddler browser extension and found root cause. I saw the POST method call not happening after preflight due to extra header in POST request which is not part of preflight OPTIONS response allow headers.

[#9 · Accepted solution]

I have fixed this issue.The first issue I highlighted was resolved once I added new header in CORS under Allow-headers.Thanks to @Sanjay Kammili, @Dino , @Mukundha Madhavan for pointing it out.

The latest issue I have posted was nothing to do with CORS.The target url was not formed correctly and once it was fixed,the whole proxy worked like charm.