Swagger UI - “ TypeError: Failed to fetch” on valid response

Question

I\'ve just pulled down the latest Swagger from the Git repo (3.0.19) using: https://github.com/swagger-api/swagger-ui.git and updated my API to use the new version.

Answer 1

This error is generic on swagger side and could be due to many possible reasons. In my case, it was due to connection error. My swagger page was not responsive due to connection issue at my side. I had to refresh it once and worked for me.

Answer 2

Every solution will definitely be correct :) But in my case I have that line in my webconfig file

 <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="5001" />  

I just replace ASPNETCORE_HTTPS_PORT to ASPNETCORE_HTTP_PORT and the error has been gone :). So the final line is

  <environmentVariable name="ASPNETCORE_HTTP_PORT" value="5001" />

replace 5001 with your port.

Answer 3

Disclaimer:- This answer is for APIs developed using Asp.net Core

I have faced similar issue when trying to access the APIs from the Swagger UI Editor. I was trying to access some APIs developed using Asp.net Core where as the Swagger UI Editor was hosted on Apache. I was facing CORS (Cross Orgin Request).

I have to modify my APIs code to allow CORS request using following code:- Declare within Startup.cs File having class "StartupShutdownHandler"

private readonly string MyAllowSpecificOrigins = "_myAllowSpecificOrigins";

Added a section of code within ConfigureServices Method.

var str = ConfigurationHandler.GetSection<string>(StringConstants.AppSettingsKeys.CORSWhitelistedURL);
        if (!string.IsNullOrEmpty(str))
        {
            services.AddCors(options =>
            {
                options.AddPolicy(MyAllowSpecificOrigins,
                builder =>
                {
                    builder.WithOrigins(str);
            });
            });
        }

Added a line of code within Configure Method.

 app.UseCors(MyAllowSpecificOrigins);

Reference Enable Cross-Origin Requests (CORS) in ASP.NET Core

Answer 4

I hit this error during local development (i.e., had nothing to do with AWS). The underlying cause (CORS violation) is identical. The following might help others who encounter this problem.

I setup connexion with an openapi spec that referred to http://localhost:9090/. When the development server starts, it says "Running on http://0.0.0.0:9090/". That page appears to work, but the swagger ui uses http://localhost:9090/ from the openapi spec for subsequent requests and shows TypeError: Failed to fetch in results. The browser console shows Access to fetch at 'http://localhost:9090/vr/variation' from origin 'http://0.0.0.0:9090'. The provided curl command worked fine; although initially confusing, the curl success is a clue that the problem is due to browser blocking rather than server-side failure.

(Connexion is based on Python flask and provides extended support for openapi integration.)

Answer 5

For anyone that runs into this problem;

After a day of troubleshooting and the Swagger support guys pointing me in the right direction, it turns out that this is currently caused by a bug within the AWS API Gateway custom authorizers.

We are currently using AWS API Gateway for managing our APIs, this includes managing all our authorization via a custom authorizer. The issue is that custom authorizers do not currently support passing through headers within the response and Swagger UI needs the Access-Control-Allow-Origin:* within the response header(s) to display the correct HTTP status code.

See this AWS thread regarding the issue (which is older than a year already):

https://forums.aws.amazon.com/thread.jspa?messageID=728839

Swagger UI discussion on same: https://github.com/swagger-api/swagger-ui/issues/3403

EDIT / UPDATE

This has since been resolved with the use of Gateway Responses. See this same forum (page 2):

https://forums.aws.amazon.com/thread.jspa?messageID=728839

Answer 6

I have encountered the same error while trying to authenticate access OAuth2 secured Rest API set. API server deployed on VM and was connecting to it using IPSEC VPN. Actually username/password in HTTP header with basic authentication was sent using separate API other than /oauth/token, backend itself was calling http://localhost:8080/api/v0/oauth/token with client secret and returning back token to client. After changing localhost to server's actual local IP , problem disappeared.