Swagger-ui: Why Swagger UI sends OPTIONS request method instead of POST

[doronMendelson]

My Swagger UI sends a OPTIONS request method instead of POST.

Why is that?

Thanks

[mohsen1]

It's because you are making cross origin requests. You need to enable CORS in your server. Read this document to learn more about cross origin XHR calls.

[doronMendelson]

I'm trying to do POST from Swagger UI under HTTP to with different domain to HTTPS on other domain.

I enabled CORS:

• About to connect() to port 443 (#0)
• Trying 127.0.0.1... connected
• Connected to (127.0.0.1) port 443 (#0)
• SSLv3, TLS handshake, Client hello (1):
• SSLv3, TLS handshake, Server hello (2):
• SSLv3, TLS handshake, CERT (11):
• SSLv3, TLS handshake, Server key exchange (12):
• SSLv3, TLS handshake, Server finished (14):
• SSLv3, TLS handshake, Client key exchange (16):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSL connection using DHE-RSA-AES256-SHA
• Server certificate:
• subject: CN=localhost
• start date: 2009-11-10 23:48:47 GMT
• expire date: 2019-11-08 23:48:47 GMT
• common name: localhost (does not match '')
• issuer: CN=localhost
• SSL certificate verify result: self signed certificate (18), continuin

GET / HTTP/1.1
User-Agent: curl/7.21.7 (amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1
Host:
Accept: _/_
Origin
Access-Control-Request-Method: POST

< HTTP/1.1 200 OK
< Date: Sun, 26 Apr 2015 13:39:49 GMT
< Server: Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.19
< X-Powered-By: PHP/5.5.19
< Access-Control-Allow-Origin:
< Access-Control-Allow-Headers: *
< Content-Length: 10
< Content-Type: text/html

Can you please see what is my problem?

Thanks

[webron]

Looks like your Access-Control-Allow-Origin has no value.

[doronMendelson]

It has a value:

• About to connect() to {domain} port 443 (#0)
• Trying 127.0.0.1... connected
• Connected to {domain}(127.0.0.1) port 443 (#0)
• SSLv3, TLS handshake, Client hello (1):
• SSLv3, TLS handshake, Server hello (2):
• SSLv3, TLS handshake, CERT (11):
• SSLv3, TLS handshake, Server key exchange (12):
• SSLv3, TLS handshake, Server finished (14):
• SSLv3, TLS handshake, Client key exchange (16):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSL connection using DHE-RSA-AES256-SHA
• Server certificate:
• subject: CN=localhost
• start date: 2009-11-10 23:48:47 GMT
• expire date: 2019-11-08 23:48:47 GMT
• common name: localhost (does not match '{domain}')
• issuer: CN=localhost
• SSL certificate verify result: self signed certificate (18), continuing anyway.

GET / HTTP/1.1
User-Agent: curl/7.21.7 (amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1.2.5
Host: {domain}
Accept: _/_
Origin {domain}
Access-Control-Request-Method: POST

< HTTP/1.1 200 OK
< Date: Mon, 27 Apr 2015 05:23:35 GMT
< Server: Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.19
< X-Powered-By: PHP/5.5.19
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: *
< Content-Length: 10
< Content-Type: text/html
<
repBad url* Connection #0 to host {domain} left intact

• Closing connection #0
• SSLv3, TLS alert, Client hello (1):

[webron]

Now you're missing the Access-Control-Allow-Methods header.

[doronMendelson]

I added it but I still can't send POST request:

• About to connect() to {domain} port 443 (#0)
• Trying 127.0.0.1... connected
• Connected to {domain} (127.0.0.1) port 443 (#0)
• SSLv3, TLS handshake, Client hello (1):
• SSLv3, TLS handshake, Server hello (2):
• SSLv3, TLS handshake, CERT (11):
• SSLv3, TLS handshake, Server key exchange (12):
• SSLv3, TLS handshake, Server finished (14):
• SSLv3, TLS handshake, Client key exchange (16):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSLv3, TLS change cipher, Client hello (1):
• SSLv3, TLS handshake, Finished (20):
• SSL connection using DHE-RSA-AES256-SHA
• Server certificate:
• subject: CN=localhost
• start date: 2009-11-10 23:48:47 GMT
• expire date: 2019-11-08 23:48:47 GMT
• common name: localhost (does not match '{domain}')
• issuer: CN=localhost
• SSL certificate verify result: self signed certificate (18), continuing anyway.

GET / HTTP/1.1
User-Agent: curl/7.21.7 (amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1.2.5
Host: {domain}
Accept: _/_
Origin {domain}
Access-Control-Request-Method: POST

< HTTP/1.1 200 OK
< Date: Mon, 27 Apr 2015 08:40:24 GMT
< Server: Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.19
< X-Powered-By: PHP/5.5.19
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: GET, POST, DELETE, PUT, PATCH, OPTIONS
< Content-Length: 10
< Content-Type: text/html
<
repBad url* Connection #0 to host {domain} left intact

• Closing connection #0
• SSLv3, TLS alert, Client hello (1):

[webron]

That tells me that it's enabled for the root of your host, but not necessarily for your API URLs. Can you try running curl -I <API URL> and paste the result here?

[doronMendelson]

Here:

HTTP/1.1 200 OK
Date: Mon, 27 Apr 2015 12:35:16 GMT
Server: Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.19
X-Powered-By: PHP/5.5.19
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT, PATCH, OPTIONS
Content-Type: text/html

[webron]

It does look right. Is your API publicly accessible?

[fehguy]

Take a look at the network response from the petstore sample. You do need the same access-control settings on both the root and the POST endpoint, as ron said.

[doronMendelson]

My API isn't public.

The problem is it doesn't send POST request. It sends OPTIONS request:

[fehguy]

This is part of CORS preflight. It is trying to see if your server is capable of POST (and other) requests so you need to either host the docs on the same host, or respond to the OPTIONS request on each endpoint.

[webron]

@doronMendelson - don't know which server you use to host your application, but it looks like it doesn't want to serve OPTIONS requests. You need to investigate how to enable that on your server.

[doronMendelson]

I was able to fix it by responding to OPTIONS request method with 200 http status.

Thanks a lot for all the help

[solsend2l]

FYI, this helped us debug a problem (we were using koa-cors' default methods). Thanks!

[doronMendelson]

I'm happy to assist

[ghost]

This does not work for me. I am getting back a 200 OPTIONS response with the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Headers: Origin, Accept, Content-Type, X-Requested-With, X-CSRF-Token

I am using 2.1.4.

[zelding]

I believe I've found the reason the UI sends OPTIONS instead of POST.
I had the same issue in two cases, but I had a lot of POST endpoint which were working fine;so i was dazzled.

Long story short: the UI sends OPTIONS if there are no formData fields in the requests definition.
After I've added a dummy field, everything was working fine.

Could this be a rare bug? It it is intentional? Can you explain this behavior?
@webron @fehguy

[fehguy]

I believe that anytime you are making a call other than GET or OPTIONS, the CORS support in browsers will automatically send an OPTIONS request to make sure it's OK to send header, etc to the server. So a formData, to any host other than the one hosting the javascript, will require a options call.

[xuanyimo]

How can I use GET?
I can get correct result with curl -X OPTIONS 'xxxxx', but can not get with swagger docs.
So, my server support OPTIONS
POST is working fine by adding formData.
Anyone get this problem?

[rubencougil]

many thanks @fehguy that helped to understand the problem here!

[savicprvoslav]

We had the same issue.

Here is a php code that shows how to deal with this issue. Please adjust it based on your own problems.

 if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
        header('Access-Control-Allow-Origin: *');
        header('Access-Control-Allow-Methods: POST, GET, DELETE, PUT, PATCH, OPTIONS');
        header('Access-Control-Allow-Headers: API-Key,accept, Content-Type');
        header('Access-Control-Max-Age: 1728000');
        header('Content-Length: 0');

        die();
    }

 header('Access-Control-Allow-Origin: *');

[vganju]

I was able to fix it by responding to OPTIONS request method with 200 http status.

Thanks a lot for all the help

Hi @doronMendelson can you please share a small code snippet regarding
responding to OPTIONS request method with 200 http status.
As as new beginner I am stuck with swagger version 2.0 will be glad if you can help me out.
Thanks for your help.

[pushpendraNoida]

I am also facing this issue. I wanted to block the preflight options request in cors.
How can do that swagger 3.0.0

[mareckste]

Same problem with swagger 3.0.0

[mehfooz-ul-haq]

check the solution

https://github.com/swagger-api/swagger-ui/issues/44#issuecomment-494700785

[bwl21]

As far as I understand, Swagger editor should send the POST requests after evaluating the response of the OPTIONS request.

But it seems not to do so.

I try to develop a Slim based server - i.e. to use the swagger-generate produced slim server.

I have added php code from https://github.com/swagger-api/swagger-ui/issues/1209#issuecomment-333789474 to send proper response to the OPTIONS request.

I also have upated .htacces accordingly.

I can see these changes in the response header of the OPTION request:

Access-Control-Allow-Headers: API-Key,accept, Content-Type
Access-Control-Allow-Methods: POST, GET, DELETE, PUT, PATCH, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Wed, 29 May 2019 13:08:46 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/7.3.3

But I still do not see swagger UI sending the POST request.