0

I'm trying to find out the problem in a communication issue between my klient and a REST API. I can identify the problem but I'm not sure what is exactly missing in the answer for the OPTION request. My application is creating a HTTP POST what is preflighted by the browser with a HTTP-OPTION. The option is asking for approving the custom Content-type. After the server answers the OPTION the POST is not sent.

OPTIONS /element_collection/VizRundown/channels/ExampleChannel/playlists/continuous/ HTTP/1.1
Host: localhost:8580
User-Agent: Mozilla/5.0.........
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US......
Origin: null

Here is how the answer looks like:

200 OK
Access-Control-Allow-Origin: *
Allow: GET, POST, OPTIONS
Content-Type: text/plain
Server: MediaSequencer/1.23.1.11957 soul/014dfd135460
Transfer-Encoding: chunked

Am I correct that there should be a line int the answer approving the requested Content-Type? Like this:

Access-Control-Allow-Headers: content-type
gbaor
  • 1,419
  • 3
  • 11
  • 19

1 Answers1

0

No, it is not required as per the relevant sections of the spec.

http://www.w3.org/TR/cors/#resource-preflight-requests:

In response to a preflight request the resource indicates which methods and headers (other than simple methods and simple headers) it is willing to handle and whether it supports credentials.

http://www.w3.org/TR/cors/#terminology:

A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Johannes
  • 763
  • 3
  • 7