Basic "Try it out" calling "OPTIONS" on wrong Scheme?

Not applicable

Foreword: I'm not the most familiar with the terminology, so I might not use the exact words, please be lenient.

I have the OpenAPI specs (Swagger Specs) for my API and created a "Spec" in the Edge portal.

I created the proxy based on that spec as passthrough, with only the "secure" enable, as I don't want to allow any non-https.

When I want to "Try it out", it always returns "TypeError: Failed to fetch".

I enabled the debug on the proxy, and noticed that it's trying to call OPTIONS, which I'm not sure why. I don't even know what "OPTIONS" is supposed to return, to be honest.

If I create a Developer Portal and add the API proxy there (through a product, etc.), I have the same behavior.

If however I use PostMan to call the proxy, it works fine. In the three scenarios, I'm authenticating with Basic Auth.

Anyone can tell me what I'm doing wrong?

Regards,

Xavier

Note: I saw this question/answer, https://community.apigee.com/questions/43405/spec-editor-try-it-out-sends-requests-via-http-whe.html, but it doesn't really help me beside telling me someone else has a similar problem.)

Solved Solved
0 7 2,190
1 ACCEPTED SOLUTION

faijahmad
Participant V

If you use the "Try it out" button and see "TypeError: Failed to fetch" in the response, then you know you need CORS.

If your not already familiar with how to implement CORS,

see: https://community.apigee.com/questions/21538/cors-preflight-and-passing-cors-header-in-response.html

View solution in original post

7 REPLIES 7

faijahmad
Participant V

If you use the "Try it out" button and see "TypeError: Failed to fetch" in the response, then you know you need CORS.

If your not already familiar with how to implement CORS,

see: https://community.apigee.com/questions/21538/cors-preflight-and-passing-cors-header-in-response.html

Check this too

Thanks for your response, however the link is broken.

Using the 2nd link you posted I see that is says it needs to implement CORS, but I find it weird that the proxy is, for all intent and purposes, working, but using their layer on top of it adds that requirement.

I'll look into implementing it, but I have a lot to catch on I guess!

Also you can go through new edge documentation

https://docs-new.apigee.com/publish-apis

see the last section "Troubleshooting issues with your published APIs" in this page

I don't know if I should create a new question or comment on this one, but I'm experiencing the same thing, and adding CORS can't help (I don't think), because that policy can't be reached.

As the OP mentioned, the Swagger editor and portal both send the request with the OPTIONS verb. Also, none of the parameters that I enter are respected:

  • The Content-Type comes through as "html/text", when I supplied "application/json".
  • My apikey header comes through as an empty string.
  • I'm not sure whether the body of the message comes through or not--I can't get that far in my proxy.

As recommended in the documentation, the AssignMessage policy that adds the CORS stuff is in the response of the PreFlow on the target endpoint. The request doesn't get anywhere close to that policy--there are a dozen other policies that fail prior to that, due to the OPTIONS verb and missing headers.

Again, as the OP posted, the curl equivalent generated by the Swagger editor and portal runs just fine, so I'm pretty sure the Swagger matches the proxy.

All of the other causes of "TypeError: Failed to fetch" seem to happen after a response (or error) has already been received from the target endpoint. In this case, I never reach the target endpoint because the request itself is so messed up.

OK, after more research, I think I understand why the OPTIONS request is being made, and why all of my headers, etc. are missing. It's a "preflight" check being done by the browser to ensure that the actual POST/GET can be done across domains.

I created a spec for the helloworld proxy that came installed in our account. It adds the CORS stuff, and the "Try it out" link in the spec I created works fine.

What seems strange to me is that when I trace the helloworld proxy, the OPTIONS request never shows up, just the GET. When I try to run my proxy, the OPTIONS request shows up.

I've modified my proxy so that, as far as I can tell, it behaves exactly the same as the helloworld proxy. That is, when an OPTIONS request comes through, it calls the add-cors policy, and that's all. I even created a new RouteRule that has no TargetEndpoint. When a POST or GET comes through, it follows a different path.

After doing all of that, I still see the OPTIONS request come through, and it sets the CORS stuff, but the GET never comes through.

So...why do I see the OPTIONS request come through on my proxy, but not on the helloworld proxy?

tyoung
Participant I

Well, I don't know if this addresses the OP's problem, but I figured mine out:

I wasn't adding the extra headers that I use for apikey, Authorization, etc. Those have to be added to the Access-Control-Allow-Headers header when you set the CORS stuff.