I am building a web API. I found whenever I use Chrome to POST, GET to my API, there is always an OPTIONS request sent before the real request, which is quite annoying. Currently, I get the server to ignore any OPTIONS requests. Now my question is what's good to send an OPTIONS request to double the server's load? Is there any way to completely stop the browser from sending OPTIONS requests?
edit 2018-09-13: added some precisions about this pre-flight request and how to avoid it at the end of this reponse.
OPTIONS requests are what we call pre-flight requests in Cross-origin resource sharing (CORS).
They are necessary when you're making requests across different origins in specific situations.
This pre-flight request is made by some browsers as a safety measure to ensure that the request being done is trusted by the server.
Meaning the server understands that the method, origin and headers being sent on the request are safe to act upon.
Your server should not ignore but handle these requests whenever you're attempting to do cross origin requests.
A good resource can be found here http://enable-cors.org/
A way to handle these to get comfortable is to ensure that for any path with OPTIONS method the server sends a response with this header
Access-Control-Allow-Origin: *
This will tell the browser that the server is willing to answer requests from any origin.
For more information on how to add CORS support to your server see the following flowchart
http://www.html5rocks.com/static/images/cors_server_flowchart.png
edit 2018-09-13
CORS OPTIONS request is triggered only in somes cases, as explained in MDN docs:
Some requests don’t trigger a CORS preflight. Those are called “simple requests” in this article, though the Fetch spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:
The only allowed methods are:
GET
HEAD
POST
Apart from the headers set automatically by the user agent (for example, Connection, User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:
Accept
Accept-Language
Content-Language
Content-Type (but note the additional requirements below)
DPR
Downlink
Save-Data
Viewport-Width
Width
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain
No event listeners are registered on any XMLHttpRequestUpload object used in the request; these are accessed using the XMLHttpRequest.upload property.
No ReadableStream object is used in the request.
Have gone through this issue, below is my conclusion to this issue and my solution.
According to the CORS strategy (highly recommend you read about it) You can't just force the browser to stop sending OPTIONS request if it thinks it needs to.
There are two ways you can work around it:
Make sure your request is a "simple request"
Set Access-Control-Max-Age for the OPTIONS request
Simple request
A simple cross-site request is one that meets all the following conditions:
The only allowed methods are:
GET
HEAD
POST
Apart from the headers set automatically by the user agent (e.g. Connection, User-Agent, etc.), the only headers which are allowed to be manually set are:
Accept
Accept-Language
Content-Language
Content-Type
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain
A simple request will not cause a pre-flight OPTIONS request.
Set a cache for the OPTIONS check
You can set a Access-Control-Max-Age for the OPTIONS request, so that it will not check the permission again until it is expired.
Access-Control-Max-Age gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request.
Limitation Noted
For Chrome, the maximum seconds for Access-Control-Max-Age is 600 which is 10 minutes, according to chrome source code
Access-Control-Max-Age only works for one resource every time, for example, GET requests with same URL path but different queries will be treated as different resources. So the request to the second resource will still trigger a preflight request.
Please refer this answer on the actual need for pre-flighted OPTIONS request: CORS - What is the motivation behind introducing preflight requests?
To disable the OPTIONS request, below conditions must be satisfied for ajax request:
Request does not set custom HTTP headers like 'application/xml' or 'application/json' etc
The request method has to be one of GET, HEAD or POST. If POST, content type should be one of application/x-www-form-urlencoded, multipart/form-data, or text/plain
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
When you have the debug console open and the Disable Cache option turned on, preflight requests will always be sent (i.e. before each and every request). if you don't disable the cache, a pre-flight request will be sent only once (per server)
Yes it's possible to avoid options request. Options request is a preflight request when you send (post) any data to another domain. It's a browser security issue. But we can use another technology: iframe transport layer. I strongly recommend you forget about any CORS configuration and use readymade solution and it will work anywhere.
Take a look here:
https://github.com/jpillora/xdomain
And working example:
http://jpillora.com/xdomain/
For a developer who understands the reason it exists but needs to access an API that doesn't handle OPTIONS calls without auth, I need a temporary answer so I can develop locally until the API owner adds proper SPA CORS support or I get a proxy API up and running.
I found you can disable CORS in Safari and Chrome on a Mac.
Disable same origin policy in Chrome
Chrome: Quit Chrome, open an terminal and paste this command: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir
Safari: Disabling same-origin policy in Safari
If you want to disable the same-origin policy on Safari (I have 9.1.1), then you only need to enable the developer menu, and select "Disable Cross-Origin Restrictions" from the develop menu.
As mentioned in previous posts already, OPTIONS requests are there for a reason. If you have an issue with large response times from your server (e.g. overseas connection) you can also have your browser cache the preflight requests.
Have your server reply with the Access-Control-Max-Age header and for requests that go to the same endpoint the preflight request will have been cached and not occur anymore.
I have solved this problem like.
if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: X-Requested-With');
header("HTTP/1.1 200 OK");
die();
}
It is only for development. With this I am waiting 9ms and 500ms and not 8s and 500ms. I can do that because production JS app will be on the same machine as production so there will be no OPTIONS but development is my local.
You can't but you could avoid CORS using JSONP.
After spending a whole day and a half trying to work through a similar problem I found it had to do with IIS.
My Web API project was set up as follows:
// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
//...
}
I did not have CORS specific config options in the web.config > system.webServer node like I have seen in so many posts
No CORS specific code in the global.asax or in the controller as a decorator
The problem was the app pool settings.
The managed pipeline mode was set to classic (changed it to integrated) and the Identity was set to Network Service (changed it to ApplicationPoolIdentity)
Changing those settings (and refreshing the app pool) fixed it for me.
OPTIONS request is a feature of web browsers, so it's not easy to disable it. But I found a way to redirect it away with proxy. It's useful in case that the service endpoint just cannot handle CORS/OPTIONS yet, maybe still under development, or mal-configured.
Steps:
Setup a reverse proxy for such requests with tools of choice (nginx, YARP, ...)
Create an endpoint just to handle the OPTIONS request. It might be easier to create a normal empty endpoint, and make sure it handles CORS well.
Configure two sets of rules for the proxy. One is to route all OPTIONS requests to the dummy endpoint above. Another to route all other requests to actual endpoint in question.
Update the web site to use proxy instead.
Basically this approach is to cheat browser that OPTIONS request works. Considering CORS is not to enhance security, but to relax the same-origin policy, I hope this trick could work for a while. :)
you can also use a API Manager (like Open Sources Gravitee.io) to prevent CORS issues between frontend app and backend services by manipulating headers in preflight.
Header used in response to a preflight request to indicate which HTTP headers can be used when making the actual request :
content-type
access-control-allow-header
authorization
x-requested-with
and specify the "allow-origin" = localhost:4200 for example
One solution I have used in the past - lets say your site is on mydomain.com, and you need to make an ajax request to foreigndomain.com
Configure an IIS rewrite from your domain to the foreign domain - e.g.
<rewrite>
<rules>
<rule name="ForeignRewrite" stopProcessing="true">
<match url="^api/v1/(.*)$" />
<action type="Rewrite" url="https://foreigndomain.com/{R:1}" />
</rule>
</rules>
</rewrite>
on your mydomain.com site - you can then make a same origin request, and there's no need for any options request :)
It can be solved in case of use of a proxy that intercept the request and write the appropriate headers.
In the particular case of Varnish these would be the rules:
if (req.http.host == "CUSTOM_URL" ) {
set resp.http.Access-Control-Allow-Origin = "*";
if (req.method == "OPTIONS") {
set resp.http.Access-Control-Max-Age = "1728000";
set resp.http.Access-Control-Allow-Methods = "GET, POST, PUT, DELETE, PATCH, OPTIONS";
set resp.http.Access-Control-Allow-Headers = "Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
set resp.http.Content-Length = "0";
set resp.http.Content-Type = "text/plain charset=UTF-8";
set resp.status = 204;
}
}
What worked for me was to import "github.com/gorilla/handlers" and then use it this way:
router := mux.NewRouter()
router.HandleFunc("/config", getConfig).Methods("GET")
router.HandleFunc("/config/emcServer", createEmcServers).Methods("POST")
headersOk := handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type"})
originsOk := handlers.AllowedOrigins([]string{"*"})
methodsOk := handlers.AllowedMethods([]string{"GET", "HEAD", "POST", "PUT", "OPTIONS"})
log.Fatal(http.ListenAndServe(":" + webServicePort, handlers.CORS(originsOk, headersOk, methodsOk)(router)))
As soon as I executed an Ajax POST request and attaching JSON data to it, Chrome would always add the Content-Type header which was not in my previous AllowedHeaders config.
When trying a CORS request on Safari 10.1, on an URL which includes query parameters (e.g. https://example.com/api?v=1), Safari says
XMLHttpRequest cannot load due to access control checks
Chrome/Firefox works fine.
On requests from the page without the ?v=1, Safari works fine too.
I tried changing the server response header from
Access-Control-Allow-Origin: https://example.com
to
Access-Control-Allow-Origin: https://example.com/api?v=1
but that breaks Chrome.
Any suggestions?
You're running into CORS issues.
Some possible causes:
The header Access-Control-Allow-Origin can only be set on server side, not in your clients script. (You did not make clear you did that correctly.)
Are you sure the protocol (http vs https vs maybe even file) is exactly the same?
If you may have multiple sub domains you need to setup your config (e.g. Apache) with something like "^http(s)?://(.+\.)?test\.com$
.
The ^ marks the start of the line to prevent anything preceeding this url. You need a protocol and allowing both here. A subdomain is optional. And the $ marks the end of line (you don't need to set sub-pages, because origin is only host based).
As stated here adding Access-Control-Allow-Headers: Origin to the server configuration as well may be a solution. Try to compare the actual requests made my Safari to the successfull requests done by Firefox or Chrome to spot possible missing Headers as well (and maybe compare them to your server configuration as well).
If anyone comes across this error, it just occurred in the application I was building. In my case, it turned out to be a trailing / in the uri, which caused a 301 response, which was for some reason interpreted by Safari as a 500 response.
Trying following might work -
Access-Control-Allow-Origin: <origin> | *
The problem is because it is necessary to be more specific in the data of the cors this does not happen in the other operating systems that do interpret it
This one worked for me for a back in php
header ("Access-Control-Allow-Headers: X-API-KEY, Origin, X-Requested-With, Content-Type, Accept, Access-Control-Request-Method");
header ("Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE");
header ("Allow: GET, POST, OPTIONS, PUT, DELETE");
$ method = $ _SERVER ['REQUEST_METHOD'];
if ($ method == "OPTIONS") {
die ();
}
Your server needs to reply to the OPTIONS http method. Not only to GET/POST/PUT/DELETE. Safari silently requests this hidden in the background. You can discover this with a MITM-attack on the connection, e.g. Fiddler.
The OPTIONS request at least needs to respond with the Cross-Origin Resource Sharing (CORS) headers, e.g.:
Access-Control-Allow-Headers
Access-Control-Allow-Methods
Access-Control-Allow-Origin
Additionally: Your Web Application Firewall (WAF) or Application Security Manager (ASM) needs to allow the OPTIONS request to pass through to your server. Often this is blocked by default, because it gives some slivers of information about the attack surface variables (http methods & headers) used by your API.
You should check the method type you calling may be - PUT, POST, GET etc.
In the following code custom header (If-Modified-Since) makes ajax fail with status HTTP/1.1 405 Not Allowed of OPTIONS preflight request. However, if I remove the header, request works well as expected (I am not sure if OPTIONS is not sent at all or dev consoles just don't show it). Why is it so? (Same situations with googleapis hosted jquery).
http = new XMLHttpRequest();
http.open('GET', 'http://code.jquery.com/jquery-2.1.4.min.js');
http.setRequestHeader('If-Modified-Since', 'Sat, 29 Oct 1994 19:43:31 GMT')
http.send();
Also, is there a way to send this header in xhr to jquery cdn to be able to get 304 reponse status?
It sounds like the Web server is saying that it doesn’t allow the OPTIONS verb (method). To confirm, check if the response includes an Allow header (per the HTTP spec, it should), and if so, what it contains. If it does not include OPTION—e.g., if it’s just Allow: GET, HEAD, PUT, then your OPTIONS request is going to always fail. So if what you want to do relies on that using OPTIONS, it’s not going to work with that server.
Per the requirements in the CORS spec, setting the If-Modified-Since header (or any other header except Accept, Accept-Language, Content-Language or a few Content-Type cases) causes the client to be required to do a preflight; and doing a preflight requires using the OPTIONS method. But neither the CORS spec nor any other spec requires that all Web servers actually must support the OPTIONS method; and in a case where a Web server doesn’t, I think you’ll get exactly the kind of response you’re seeing here.
I am using pysimplesoap APIs to support a SOAP server with the following code :
httpd = BaseHTTPServer.HTTPServer(("", 8008), SOAPHandler)
httpd.dispatcher = dispatcher
httpd.serve_forever()
This works well, but not if requests are generated using JS/XMLHttpRequest (CORS issue), as the default implementation of SOAPHandler does not support the OPTIONS method. I added this :
class MySOAPHandler(SOAPHandler):
def do_OPTIONS(self):
self.send_response(200)
self.send_header('Access-Control-Allow-Origin', '*')
self.send_header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')
self.send_header("Access-Control-Allow-Headers", "X-Requested-With")
self.end_headers()
But the code still does not support CORS requests and the HTTP status is 0?
CORS is a particularly stubborn standard. Your static response for Options will not work for anything but the "basic" requests. You need to make a few changes:
Access-Control-Allow-Origin may not be wildcard. It has to be a specific domain. Just look at the request header and echo back the Origin field.
Access-Control-Allow-Headers should also be dynamic since clients/JS tend to throw wacky stuff in there. Echo back the Access-Control-Request-Headers field.
Also add in a Access-Control-Allow-Credentials: true header.
For debugging, to keep yourself sane, put in a Access-Control-Max-Age: 1 header. Without this header the browser will cache the results of the OPTIONS request for a long time. This is fine for production deployment but for testing it just gets annoying.
For a project I'm looking at various HTML5 and Javascript elements and security around them and I'm trying to get my head around CORS just now.
Based on my testing, if I remove..
<?php
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
?>
..from the page that is trying to be accessed I see the following in the console log on Chrome:
XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.
I understand this to be correct, however Wireshark shows HTTP/1.1 200 OK in the return and in the data shows the source of the page being requested. So is it just the browser and Javascript that is blocking responseText from being used in any substantial way even though it's actually transferred?
The code is just as below:
function makeXMLRequest() {
xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) {
alert(xmlhttp.responseText);
}
}
xmlhttp.open("GET","http://www.bla.com/index.php",true);
xmlhttp.send();
}
Thanks in advance.
For a "simple" HTTP verb like GET or POST, yes, the entire page is fetched, and then the browser decides whether JavaScript gets to use the contents or not. The server doesn't need to know where the requests comes from; it is the browser's job to inspect the reply from the server and determine if JS is permitted to see the contents.
For a "non-simple" HTTP verb like PUT or DELETE, the browser issues a "preflight request" using an OPTIONS request. In that case, the browser first checks to see if the domain and the verb are supported, by checking for Access-Control-Allow-Origin and Access-Control-Allow-Methods, respectively. (See the "Handling a Not-So-Simple Request" on the CORS page of HTML5 Rocks for more information.) The preflight response also lists permissible non-simple headers, included in Access-Control-Allow-Headers.
This is because allowing a client to send a DELETE request to the server could be very bad, even if JavaScript never gets to see the cross-domain result -- again, remember that the server is generally not under any obligation to verify that the request is coming from a legitimate domain (although it may do so using the Origin header from the request).
So is it just the browser and Javascript that is blocking responseText from being used in any substantial way even though it's actually transferred?
Yes. You can make any request you like with JS.
It is access to the data that the same origin policy prevents.
Requests which do malicious things (such as "POST http://bank.example/give/money?to=attacker" or "POST http://forum.example.com/post?message=spamspamspamspam") are called CSRF attacks and have to be defended against by the server.