CORS preflight requests require Content-Type: application/json

[epheph]

A recent PR, #15220 enforces the presence of the request header:
Content-Type: application/json

However, this check ALSO applies to CORS preflight requests (OPTIONS). As an example, this curl fails:

$ curl localhost:8545 -X OPTIONS -H 'access-control-request-method: POST' -H 'origin: http://127.0.0.1:8080'  -H 'authority: localhost:8545' -H 'access-control-request-headers: content-type' --compressed -v  -k
...
> OPTIONS / HTTP/1.1
> Host: localhost:8545
> User-Agent: curl/7.54.0
> Accept: */*
> Accept-Encoding: deflate, gzip
> access-control-request-method: POST
> origin: http://127.0.0.1:8080
> authority: localhost:8545
> access-control-request-headers: content-type
>
< HTTP/1.1 415 Unsupported Media Type
...SNIP...
invalid content type, only application/json is supported

But adding -H "Content-type: application/json" allows the pre-flight to proceed

$ curl localhost:8545 -X OPTIONS -H 'access-control-request-method: POST' -H 'origin: http://127.0.0.1:8080'  -H 'authority: localhost:8545' -H 'access-control-request-headers: content-type' --compressed -v -H "Content-type: application/json"
...
> OPTIONS / HTTP/1.1
> Host: localhost:8545
> User-Agent: curl/7.54.0
> Accept: */*
> Accept-Encoding: deflate, gzip
> access-control-request-method: POST
> origin: http://127.0.0.1:8080
> authority: localhost:8545
> access-control-request-headers: content-type
> Content-type: application/json
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Fri, 22 Dec 2017 21:10:40 GMT
< Content-Length: 0
<

However, browser do not, and cannot, include that header in pre-flights. In fact, this specific pre-flight (from Chrome) was asking if it was OK to send along Content-type as a header (and the response was "please send along content-type if you'd like me to answer that!").

Also, the content-type of the request specifies the request body, which is not applicable to an OPTIONS request.

I imagine the solution here is to exclude pre-flight requests from this check.

System information

Geth version: geth version

Version: 1.8.0-unstable
Git Commit: 5f8888e11606296c9582496974c0f6b96a882146
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.9.2
Operating System: linux
GOPATH=
GOROOT=/usr/local/go

OS & Version: Linux
Commit hash : 5f8888e11606296c9582496974c0f6b96a882146

Expected behaviour

A pre-flight OPTIONS request should succeed without the presence of "Content-Type" header

Actual behaviour

A pre-flight OPTIONS request responds with 415 without the presence of "Content-Type" header

Steps to reproduce the behaviour

Run the curl commands in the above narrative

Backtrace

n/a

/cc @bas-vk

[sorin]

@epheph I think you are correct - an OPTIONS request should not have to specify a content type- especially since it has no body
PR here: #15759