CORS handling without headers

[a-dma]

When sending a preflighted cross-origin request, the leading OPTIONS request is expected to have the Access-Control-Request-Headers header set.

The specs are a bit ambiguous about whether or not the header is mandatory.

The CORS Middleware in actix-web is expecting the header to always be set, but I found that at least Firefox is not setting that header in the OPTIONS request if the following request doesn't contain any header.

I can temporarily circumvent this by setting a dummy custom header to force Firefox to set Access-Control-Request-Headers, or by disabling the preflight handling on actix's side and implementing that manually, but I think it should be handled differently in the Middleware itself.

[DoumanAsh]

Hmmm could you please elaborate on specific wording on what spec says about existence of this header?

If it doesn't say SHOULD or MUST then I guess it might be worth considering treating it as such or having option to allow missing header

[a-dma]

There is a link in the original issue, I'll add it again here to that you can judge for yourself

https://fetch.spec.whatwg.org/#http-requests

[DoumanAsh]

For some reason I cannot access it from my office, I'll check it after work

[a-dma]

There you go

3.2.2. HTTP requests

A CORS request is an HTTP request that includes an Origin header. It cannot be reliably identified as participating in the CORS protocol as the Origin header is also included for all requests whose method is neither GET nor HEAD.

A CORS-preflight request is a CORS request that checks to see if the CORS protocol is understood. It uses OPTIONS as method and includes these headers:

Access-Control-Request-Method

Indicates which method a future CORS request to the same resource might use.

Access-Control-Request-Headers

Indicates which headers a future CORS request to the same resource might use.

Also the raw version is available at https://github.com/whatwg/fetch/blob/master/fetch.bs#L2410

[DoumanAsh]

Hm... from this alone I'm bit unsure if it is allowed to omit this header.

From the quote itself it seems that it should include these headers

MDN says:

This header is required if the request has an Access-Control-Request-Headers header.

The question is how should we treat missing header?

[a-dma]

I think the language in the fetch specs could be clearer, especially since they use must and must not in other parts.

To me the fact that Firefox does not send that header in some cases is reason enough make it optional and map that to the same behavior that you would have if the header were present and with an empty value, i.e. no headers allowed in the next request.

[DoumanAsh]

To me the fact that Firefox does not send that header in some cases is reason enough make it optional

This is not really all that straightforward to me. IF it is firefox, it doesn't mean that it 100% correct.
I guess I'd need to take a look at CORS implementation in other web libraries to see how they treat such CORS requests

[avitex]

While the specification is not very specific; if a user wishes to make a request without any additional headers, Access-Control-Request-Headers would have to be either present and empty OR optional. As per the WHATWG specification, the value is defined as:

Access-Control-Request-Headers   = 1#field-name

This means the header must have at least one field-name to be valid. This implies that if a user does not wish to specify additional request headers, the request could only be valid if the header is optional.

This infact is how every other major implementation I know of does it.

Also, the current implementation incorrectly allows Access-Control-Request-Headers to be empty, which is directly contradicts the specification.

PR in the works to resolve this.

[fafhrd91]

fixed by #816