When the DefaultCorsProrocessor successfully handles a pre-flight request and returns a response that has an HTTP 200 status code, but it's arguably more correct to return a 204 as there is no content. It is also clearer that something out of the ordinary is happening as it's less common to have a 204 response than a 200 which may help when debugging issues.
Changing this may break some tests as rather than just testing that a request is ok, developers may be explicitly be checking for a 200 status code.
This is how an example pre-flight request currently looks:
> OPTIONS / HTTP/1.1
> Host: localhost:8443
> User-Agent: curl/7.64.1
> Accept: */*
> Origin: https://localhost:3000
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: Content-Type
>
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Access-Control-Allow-Origin: https://localhost:3000
< Access-Control-Allow-Methods: GET,HEAD,DELETE,PUT,PATCH,POST
< Access-Control-Allow-Headers: Content-Type
< Access-Control-Allow-Credentials: true
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
< Content-Length: 0
< Date: Mon, 17 Feb 2020 09:55:47 GMT
<
Comment From: rstoyanchev
The CORS spec allows it:
HTTP status code is in the 2xx range
The question is if browsers handle it without any issues.
Comment From: rstoyanchev
I don't think we'll change anything here. An OPTIONS request isn't expected to have a body in any case.