CORS handling seems broken

[RenFontes]

They return only a NetworkError with no more information, EVEN when the response had a 200 status and a correct response.

It happened to me while trying to run the http example locally -> https://guide.elm-lang.org/effects/http.html (only change made was to be able to get the error and print it using Debug.toString)

And also when trying to run the same example but pointing the url to a locally running express endpoint with cors enabled for all urls.

I also tried it with some test api I found on google and that seemed to work correctly. Not sure if Elm is expecting some headers not provided by express by default or is there is something else I should be doing.

[2mol]

same issue as elm/elm-lang.org#829

[RenFontes]

By the way, this issue does not happen when using an F# + giraffe + .net core backend.

Not sure if elm was expecting something else not provided by express, but the fact that the request is successful makes me think that it should had been successful for elm too, or that elm should at least give a more descriptive error. (Specially since it prides itself in its descriptive errors)

[2mol]

Could you check if your .net core app does a preflight request? You should see one in the networks tab that is OPTIONS instead of GET.

I think elm the language is not doing much wrong here. The good error messages with regards to the compiler don't apply here, since this is a problem that occurs during runtime. But I agree that the Http library could maybe pass more fine-grained information that just NetworkError.

[HenkPoley]

Just a slight hint: Under Safari/WebKit the server also needs to respond to the OPTIONS method with the CORS headers. Not only on the GET/POST/PUT/DELETE. This OPTIONS request is silently sent, and can often only be found with a MITM attack on the connection, like Charles Proxy or Fiddler.