Why does Fetch API Send the first PUT request as OPTIONS - javascript

I am trying to make a cors PUT request using the vanilla Fetch API
When I click my button to send the PUT request, the method on the first request is OPTIONS. It is only when I click the button again, then the method on the request changes to PUT. Why?
I understand this is part of the CORS preflight, but is there a way to trigger the preflight manually so the OPTIONS response can be cached?
Could this behavior be indicative of a failing promise somewhere?

See the Fetch Standard, section 4.7. CORS-preflight fetch.
Note: This is effectively the user agent implementation of the check to see if the CORS protocol is understood. The so-called CORS-preflight request. If successful it populates the CORS-preflight cache to minimize the number of these fetches.
at steps 1 through 7; also 4.8. CORS-preflight cache.

Related

why Axios send two request

I need help with axios, I don't know why is sending two request here an image of chrome network in one post call
I'm using react, and when I send request the function only trigger once (I debugged and put console.logs and get one response) but in chrome network I got two request, with different headers and type.
One have Authorization token, and the other don't have tokensuccess request and
wrong request this is in one call and I don't know what is happening.
Thanks for your time!
Is it an OPTION request?. OPTION requests are used to check if your client has permission to make the desired request to the API.
The HTTP OPTIONS method requests permitted communication options for a given URL or server. A client can specify a URL with this method, or an asterisk (*) to refer to the entire server.

Is there a way to know if a GraphQL request was sent raw or through the Playground?

We are doing some header checking in our Apollo GraphQL application and noticed that when the user sends a request to initially open Playground in the browser, there are no headers present in this request.
The problem is that in our application, all requests are supposed to contain at least some required headers. If these headers are missing, our code flags these requests and determines the request is not genuine. Therefore, a request to open Playground is flagged because it is missing these required headers.
Is there any way to distinguish whether the incoming request is requesting Playground versus a request that is actually making a call for some data? Is there an attribute somewhere?

Getting error: XMLHttpRequest cannot load - Response for preflight has invalid HTTP status code 405

I am using ionic framework and angular js, I use chrome for viewing my logs but here I am doing a login page I am trying to post the user entered data to serve but I am getting this error like -
XMLHttpRequest cannot load - Response for preflight has invalid HTTP status code 405.
My code works fine on a device but I am getting the error in chrome. Anyone know the root cause of this error.
Cross-Origin Resource Sharing actually specifies that two requests should be made to the server on an AJAX call (if certain conditions apply, like sending custom headers).
The first request (the one with the OPTIONS method) is called pre-flight and is used to check if it's safe to send the full request to the server. The response from the server should contain a valid Access-Control-Allow-Origin header containing the URL of the client or *.
HTTP 405 means Method Not Allowed. You may be sending the request with a different method on chrome. If you try the URL directly in browser it triggers a GET request on that URL.

How to modify request bodies by chrome extension

I've tried use chrome.webRequest API and finally found out that it looks like google don't allow us to modify requestBodies of POST requests? I could only cancel it or modify its headers.
So is there any other way to modify the raw (not form) body of a post request? I know that a proxy server could do that but I want to deal with it using extension.
This works for some cases: first, save the body of the request in a variable in the onBeforeRequest listener. Then, in onBeforeSendHeaders you can either cancel or redirect the original request (sorry, Chrome gives you only two options to deal with the original). Also in onBeforeSendHeaders, you issue a new request (say, jquery ajax) to which you attach the old body from the variable, and the old headers - both can be modified/rewritten as needed.
(Minor catch: it won't let you set all of the headers for "security reasons", so you may add one more onBeforeSendHeaders listener to add the sensitive headers to the new request as well).
Works for cases when the request issuer is happy with a redirect or cancel as a response. If the request issuer expects the full actual response, intact, with no redirects, then it gets harder.
Chrome extension Netify allows request modification, including POST body

Repeated OPTIONS requests for cors / ajax requests

On my site I have an auto-suggest text input that suggests results as the user types. The results are provided by a AJAX calls to an API on a different domain. This means I have to use CORS to allow the requests.
It is all working quite well, but every time the user types a new character, the browser sends a new OPTIONS request to ensure it is authorized.
Is there a way around all these repeated options requests?
My php script receiving the requests has
header("Access-Control-Allow-Origin: http://consent.example.com");
and the requests are all originating from consent.example.com. To be clear, the authorization works just fine, and the request completes successfully, but I don't know why it needs to keep making options calls. It would make sense to me that the browser would cache this.
According to RFC 2616 ("Hypertext Transfer Protocol -- HTTP/1.1"), section 9.2:
9.2 OPTIONS
...
Responses to this method are not cacheable.
The HTTP spec explicitly disallows caching OPTIONS responses.
It is worth noting that the GET responses do not employ caching either (I see that customers?search=alex is 200 each time). This is simply because the server chooses not to send 304 responses for that request, or your browser doesn't let the server know it has a cached copy, by an If-Modified-Since or If-None-Match request header.

Categories

Resources