After looking at it, here's the list of optional headers we might be
interested in :
Indicates whether a resource can be shared, via returning the literal value
of the Origin request header (which can be `null`) or `*` in a response.
Indicates whether a resource can be shared when request's credentials mode
For a CORS preflight request, request's credentials mode is always omit,
but for any subsequent CORS requests it might not be. Support therefore
needs to be indicated as part of the HTTP response to the CORS preflight
request as well.
An HTTP response to a CORS preflight request can include the following
Indicates which methods are supported by the resource for the purposes of
the CORS protocol.
The `Allow` header is not relevant for the purposes of the CORS protocol.
Indicates which headers are supported by the resource for the purposes of
the CORS protocol.
Indicates how long the information provided by the
`Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` headers
can be cached.
An HTTP response to a CORS request that is not a CORS preflight request can
also include the following header:
Indicates which headers can be exposed as part of the HTTP response, via
listing their names.
Should we make an option per header (sounds plain silly to me), or keep the
current code that let the user says which header(s) she wants ?
2014-12-04 6:57 GMT+01:00 Max Kellermann m...@duempel.org:
On 2014/12/03 23:09, X Ryl boite.pour.s...@gmail.com wrote:
Actually, it's useful to clients but not only. In my use case, MPD is
on a headless server. Without it, it's not possible to receive this
browsers. That prevents using HTTPD plugin as a audio source for a web
page, unless you have the Allow Origin header (ditto for
An option for generating that one header sounds acceptable. But what
you wrote is hard to understand, hard to configure and error prone.
mpd-devel mailing list