Why does body-parser fail when I fetch the resource in 'no-cors' mode?

Question

I open a static page from the file system which tries to fetch a resource from a server running on localhost ( namely a directory listing of / ). The browser refuses to forward this request and suggests:

If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Then I submit the request using 'no-cors':

let body=JSON.stringify({action:"listfiles",path:"/"})

let headers = new Headers()
headers.append("Content-Type", "application/json");               

fetch('http://localhost:9000/ajax',{
    method: 'POST',
    headers: headers,
    body: body,
    mode: 'no-cors'
}).then(
    response=>response.json()
).then(
    data=>this.onload(data)
)

On the server side I use express in the following way:

app.use('/ajax',bodyParser.json())

app.post("/ajax",function(req,res){    
  let action=req.body.action  
  console.log(`ajax ${action}`)
}

This time the browser lets the request through, and even app.post gets the request, just the request body is not parsed correctly, instead of 'listfiles' I get undefined value for action. ( The same problem does not occur if I load the page from localhost ).

Answer 1

Because you're trying to make a cross-origin call (the protocol file: is not the same as the protocol http:). The Same Origin Protocol is enforced by the browser, so it's not surprising your server sees the request. The request doesn't contain CORS headers that would allow the browser to give the response to your code, so it doesn't; and you've disabled CORS anyway.

Answer 2

From https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS :

" The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser. Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. "

The problem with my request is that it does not qualify as simple. This is because it contains a Content-Type: application/json header, in order that the body-parser middle-ware would parse the document body as json. Therefore it triggers a preflight request.

" Simple requests

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: ... "

Conditions listed here include restrictions on methods, the headers you can set etc. Please look at the doc for details.

While the method I use ( POST ) is allowed in a simple request, and also setting the Content-Type header is allowed for a simple request, the only possible values for Content-Type are

application/x-www-form-urlencoded
multipart/form-data
text/plain

for a request to qualify as simple.

Since my server does not know about preflight requests, it is natural that it could not handle my request properly.

Also see the comment to the answer, as to which additional headers need to be passed on the client and the server side for the request to work as expected.