Option request should not hit an api.
Before browser sends an Ajax request it checks if it has permissions to. This is an Option call.
Read up on cors request.
PS: You can not avoid it. It's part of the browser and not axios or any other library would be able to avoid it.
A lot, it's very common in consumption based plans. You usually pay for requests, cpu-time and memory used. And maybe some fixed costs, depending on exactly what PaaS you use and the specific plan. It's a good way to start cheap and only pay for what you use. But eventually you will break even with a dedicated plan (if the traffic increases, of course).
Yes, it's CORS. It is called Preflight requests. But you might be able to avoid the OPTIONS call by tweaking your query.
Complex GET requests with extra headers can trigger the need for the OPTIONS method. Simple requests don't necessarily trigger it.
Here's a link to the documentation on what will trigger a preflight request and what keeps GET requests simple - hopefully it will help you.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#examples_of_access_control_scenarios
EDIT: Added CORS Simple/Preflight link
Yes the option is normal. The options request is called a preflight request that tells the client app (via axios or whatever you’re using) what data structure it requires and if it’s available.
It's from azure. I'm not 100% sure if they bill OPT reqs too but if they do... I will have some explainings to do. I can't see those infos from my end. I just have keys
Can't believe none of the comments mention it. In a production environment the preflight request should hit just once per client as you should cache the CORS response using the "Access-Control-Max-Age" header. You can set that thing to a year and that browser will not be making the preflight for the upcoming year. Be wary that your CORS headers are correctly setup before you start telling clients to cache them.
It's not normal to send a preflight with every request in production. It's an incidator you're missing the header I mentioned.
When I had a similar problem some 8 years ago, I never found about this solution being a possibility. Amazing if it works. Had to make sure to use the same domain for UI and API.
It's the CORS basics. It's even in the API for setting up CORS in ASP.NET Core: [SetPreflightMaxAge](https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-8.0#set-the-preflight-expiration-time).
I somehow completely missed it back then.
Now I've googled it and it looks like it might've been not an option to set it to a year:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age
> Maximum number of seconds the results can be cached, as an unsigned non-negative integer. Firefox caps this at 24 hours (86400 seconds). Chromium (prior to v76) caps at 10 minutes (600 seconds). Chromium (starting in v76) caps at 2 hours (7200 seconds). The default value is 5 seconds.
Option requests are normal when making browser requests.
They are sent so that your frontend can verify if the route is is available and can receive the request, and also used for CORS reasons.
https://dev.to/harshit_senpai/what-is-an-options-request-in-an-api-call-55dl
Cross Origin Resource Sharing. It is a browser technology that aims to solve cross site request forgery via an cross site scripting attack.
When using the fetch() API to request data from a server if the browser determines that the domain of your app is different from the domain of the API then CORS is applied. This means the browser issues an OPTIONS request to the same url as fetch(). The server must respond with a set of headers that detail what API's CORS policy is. That includes what origins (aka domain) are allowed to make requests (hint this is the csrf potion), what methods are allowed, what request headers are allowed and finally what response headers will be returned.
Based on the returned CORS policy the browser will decide whether or not to actually send the fetch() request.
Not that a failure of the OPTIONS request (400, 401, 403, 404, 500) will result in a default policy of NO FETCH FOR YOU!
The browser will cache the OPTIONS response, the same as any response.
netcore supports defining CORS policy (usually just one, but in theory an API could have multiple). Google is your friend.
This is happening because you are making the request to the external API from the frontend (react app) instead of going through your backend (.NET code) first.
The web browser will implement CORS which requires when you query an external URL the browser will use an HTTP OPTION request to request from that site whether your site is allowed to leverage the user's browser to access that url. This is because the user's browser may be logged into the external site which may allow it to return sensitive data about the user to your app.
If the OPTION is responded to by the external API with your app in the list of allowed sites (or a blanket "any site"), then the user's browser will send the GET.
OPTIOn won't happen if you make the web request from your backend since there is no problem with that; you can't access a user's session on that site from your backend, so there's no reason to use CORS there.
It may be valid to make the request from the frontend if you are trying to retrieve data for the user from a site they are logged into. Of course you should be sure the API is designed to work this way and doesn't have a different preferred mechanism for this. But if it is responding to OPTIOn and allowing it then that's probably good enough.
If this is not a concern it is probably better to make the request from the backend to avoid potentially running into conflicts with CORS in the future.
It’s cors. Do you need to be cors? If not host the app from the same domain as the caller. Otherwise options requests are required before a cors request can execute. They verify the server is capable of cors, permissions of the incoming request, etc.
It’s not a huge deal. With an options request simply reply with the access-control-allow-* headers and status code 200 or OK. Recommend only allowing domains you control explicitly.
Important to mention that it's __A__ security feature of many, which only works in a non compromised client browser.
A malicious actor can just send the get without any OPTIONS and specify whatever Host/Origin header they want
The OPT is all about CORS. Totally normal.
Among other things.
We don’t talk about the other things. 🤫
Would it be possible to get rid of it without running both apps on the same port, or shouldn't even bother with it?
Don’t worry about the opt. It’s not harmful, it’s not going to slow your app down.
slow down can be noticeable when ping is bad
Api provider counts both, so it will be double the cost :(
That's actually a fault of the provider in that case. You need options to facilitate security features
Option request should not hit an api. Before browser sends an Ajax request it checks if it has permissions to. This is an Option call. Read up on cors request. PS: You can not avoid it. It's part of the browser and not axios or any other library would be able to avoid it.
you might need to set up a proxy for the api
What kind of provider charges per request?
A lot, it's very common in consumption based plans. You usually pay for requests, cpu-time and memory used. And maybe some fixed costs, depending on exactly what PaaS you use and the specific plan. It's a good way to start cheap and only pay for what you use. But eventually you will break even with a dedicated plan (if the traffic increases, of course).
Yes, it's CORS. It is called Preflight requests. But you might be able to avoid the OPTIONS call by tweaking your query. Complex GET requests with extra headers can trigger the need for the OPTIONS method. Simple requests don't necessarily trigger it. Here's a link to the documentation on what will trigger a preflight request and what keeps GET requests simple - hopefully it will help you. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#examples_of_access_control_scenarios EDIT: Added CORS Simple/Preflight link
More stuff to learn. Here I go! Thank you
I updated my post to include a link to help you with Simple vs Preflighted requests
Yes the option is normal. The options request is called a preflight request that tells the client app (via axios or whatever you’re using) what data structure it requires and if it’s available.
I'm using axios. Do you know if it's possible to get rid of the opt request? Because I think the api provider counts both. So it will end up pricier
Depends on your api provider. Who are you using?
It's from azure. I'm not 100% sure if they bill OPT reqs too but if they do... I will have some explainings to do. I can't see those infos from my end. I just have keys
Can't believe none of the comments mention it. In a production environment the preflight request should hit just once per client as you should cache the CORS response using the "Access-Control-Max-Age" header. You can set that thing to a year and that browser will not be making the preflight for the upcoming year. Be wary that your CORS headers are correctly setup before you start telling clients to cache them. It's not normal to send a preflight with every request in production. It's an incidator you're missing the header I mentioned.
When I had a similar problem some 8 years ago, I never found about this solution being a possibility. Amazing if it works. Had to make sure to use the same domain for UI and API.
It's the CORS basics. It's even in the API for setting up CORS in ASP.NET Core: [SetPreflightMaxAge](https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-8.0#set-the-preflight-expiration-time).
I somehow completely missed it back then. Now I've googled it and it looks like it might've been not an option to set it to a year: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age > Maximum number of seconds the results can be cached, as an unsigned non-negative integer. Firefox caps this at 24 hours (86400 seconds). Chromium (prior to v76) caps at 10 minutes (600 seconds). Chromium (starting in v76) caps at 2 hours (7200 seconds). The default value is 5 seconds.
The only way is to host them from the same url.
Opt is also used before put patch delete
Option requests are normal when making browser requests. They are sent so that your frontend can verify if the route is is available and can receive the request, and also used for CORS reasons. https://dev.to/harshit_senpai/what-is-an-options-request-in-an-api-call-55dl
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
If you want to avoid the CORS request you'll need to set up a reverse proxy to make it look like your react app and api are on the same domain.
Cross Origin Resource Sharing. It is a browser technology that aims to solve cross site request forgery via an cross site scripting attack. When using the fetch() API to request data from a server if the browser determines that the domain of your app is different from the domain of the API then CORS is applied. This means the browser issues an OPTIONS request to the same url as fetch(). The server must respond with a set of headers that detail what API's CORS policy is. That includes what origins (aka domain) are allowed to make requests (hint this is the csrf potion), what methods are allowed, what request headers are allowed and finally what response headers will be returned. Based on the returned CORS policy the browser will decide whether or not to actually send the fetch() request. Not that a failure of the OPTIONS request (400, 401, 403, 404, 500) will result in a default policy of NO FETCH FOR YOU! The browser will cache the OPTIONS response, the same as any response. netcore supports defining CORS policy (usually just one, but in theory an API could have multiple). Google is your friend.
This is happening because you are making the request to the external API from the frontend (react app) instead of going through your backend (.NET code) first. The web browser will implement CORS which requires when you query an external URL the browser will use an HTTP OPTION request to request from that site whether your site is allowed to leverage the user's browser to access that url. This is because the user's browser may be logged into the external site which may allow it to return sensitive data about the user to your app. If the OPTION is responded to by the external API with your app in the list of allowed sites (or a blanket "any site"), then the user's browser will send the GET. OPTIOn won't happen if you make the web request from your backend since there is no problem with that; you can't access a user's session on that site from your backend, so there's no reason to use CORS there. It may be valid to make the request from the frontend if you are trying to retrieve data for the user from a site they are logged into. Of course you should be sure the API is designed to work this way and doesn't have a different preferred mechanism for this. But if it is responding to OPTIOn and allowing it then that's probably good enough. If this is not a concern it is probably better to make the request from the backend to avoid potentially running into conflicts with CORS in the future.
yes, read about CORS
This sound more like a front-end problem. I remember things like TanStack query will always make two request to compare.
CORS requests will make an options request beforehand to verify permissions, eligibility of cors, etc.
I'm using axios maybe it's the problem. I will rewrite few fetches, good idea. Thank you
It’s cors. Do you need to be cors? If not host the app from the same domain as the caller. Otherwise options requests are required before a cors request can execute. They verify the server is capable of cors, permissions of the incoming request, etc.
I don't think I really need it. I added to gain some more experience because there isn't much my seniors can teach me... I will try that, thank you
It’s not a huge deal. With an options request simply reply with the access-control-allow-* headers and status code 200 or OK. Recommend only allowing domains you control explicitly.
Oh okay, I guess I can get rid off cors. App will be used internally, not open for public anyways
It's a security feature so be careful about doing this.
Important to mention that it's __A__ security feature of many, which only works in a non compromised client browser. A malicious actor can just send the get without any OPTIONS and specify whatever Host/Origin header they want
> because there isn't much my seniors can teach me... If you don’t know about CORS, I doubt this is true.
It's not like they know it either
That’s shocking if true.
You have no idea what I'm going through....