preflight

My web client application is setting HTTP POST requests via fetch API. I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab. I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back? You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome. This is an expected behavior change according to: https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1 I originally came

My FE application is using API from different domain. I know that it should trigger CORS, but as I understood it shouldn't create preflight for every request. According to docs , I shouldn't have preflight request for GET method. Cross-site requests are preflighted like this since they may have implications to user data. In particular, a request is preflighted if: - It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML

My function in an Angular service component to POST a request to create a new weather station with openweathermap.org: registerStation(registerWeatherStation: RegisterWeatherStation): Observable<Response> { let params = JSON.stringify(registerWeatherStation) console.log("params: ",params) let header = new Headers({'Content-Type': 'application/json; charset=utf-8'}) let options = new RequestOptions({ headers: header }) let url = this.servUrl + 'stations?appid=' + this.weatherAppId return this .http .post(url, params, options) } This is from Chrome's Developer Tools Network Tab showing activity

I need to make an HTTP GET request with custom request headers in-browser and process the result as it streams in. The Fetch API is ideal for this: fetch('https://example.com/resource', { method: 'GET', headers: { 'X-Brad-Test': 'true' }, cache: 'no-store', mode: 'cors' }).then((res) => { const reader = res.body.getReader(); // etc. }); This works quite well. Since there are custom headers, the browser pre-flights the request with an OPTIONS request to /resource . I have configured my server to respond with a 204 No Content and the following headers: Access-Control-Allow-Headers: X-Requested

So I'm writing this RESTful backend in Go, which will be called with cross-site HTTP requests, i.e. from content served by another site (actually, just another port, but the same-origin policy kicks in, so here we are). In this scenario, the user agent will, in some cases, send preflight OPTIONS requests to check if the actual request is safe to send. My question is how to best deal with, and adequately respond to, these preflight requests in a Go context. The ways I have conceived don't feel very elegant, and I'm wondering if there's some other approach to this that I haven't thought of.

General: Request URL:x/site.php Request Method:OPTIONS Status Code:302 Found Remote Address:x.x.x.x:80 Response Headers: view source Access-Control-Allow-Headers:Content-Type Access-Control-Allow-Origin:* Access-Control-Max-Age:300 Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Content-Length:0 Content-Type:text/html; charset=UTF-8 Date:Thu, 02 Mar 2017 14:27:21 GMT Expires:Thu, 19 Nov 1981 08:52:00 GMT Location:y Pragma:no-cache Server:Apache/2.4.25 (Ubuntu) Request Headers: view source Accept:*/* Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8