4 ms·
I know it well enough that changing to a custom mime-type like "text/x-myapp-foo" is a solution that gets around CORS and pre-flight as well in the latest versi
by officialchicken 8y ago
I know it well enough that changing to a custom mime-type like "text/x-myapp-foo" is a solution that gets around CORS and pre-flight as well in the latest version of Chrome.
- mahesh_rm 8y agoCan you elaborate on this / link to a more detailed spec?
- Klathmon 8y agoAre you sure? That's a pretty insane security issue if it's true! Content-Type should only be allowed to be `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` to be allowed without preflight. Edit: I can't reproduce this on Chrome 69.0.3497.100 (Official Build) (64-bit). Setting the Content-Type to anything other than the above with a POST request will cause an OPTIONS preflight, even when using your example.
- officialchicken 8y agoI'm using 69.0.3497.81. Make sure your server accepts the header... after changing I stopped seeing OPTIONS requests in my server logs, not that it measurably improved the speed of the SPA. It was several months ago I made the change and FF behavior is definitely different (more relaxed?) than Chrome when it comes to CORS.
- TeMPOraL 8y agoThere's caching for successful preflights; maybe it's involved here?
- breatheoften 8y agoI know that chrome limits the amount of time that the CORS preflight validation response result can be cached (to a maximum of 5 minutes — and if the server sets expiration header to a longer time - chrome still only caches up to 5 minutes). Does Firefox perhaps not limit this? It could be that you are seeing a difference in behavior due to the max time that each browser is willing to cache the CORS preflight check ...?