Allowing all headers should be removed

[neomerx]

Currently there is a config option Settings::VALUE_ALLOW_ALL_HEADERS which should allow all headers pass through CORS. It works fine for internal lib logic. No problem here. The problem is that this value * is actually sent to client in Access-Control-Allow-Headers and browser don't understand this value.

It looks the only possible way is listing all allowed headers and special * should be removed.

It was added mostly to make development easier. However since logging has been added to the lib this feature is not so important.

It is recommended avoid using Settings::VALUE_ALLOW_ALL_HEADERS and just list all allowed headers in Settings::KEY_ALLOWED_HEADERS

[neomerx]

Proposed solution: mark the constant as depreciated and do not sent it to client (it's not recognizable anyway).

[neomerx]

link here original idea #15

[barryvdh]

Allow all headers could just return all requested headers, right?

[neomerx]

@barryvdh It's related to Access-Control-Allow-Headers header. On preflight request CORS should reply with a list of headers it allows browser to send in the actual request (which comes right after the preflight request). Initially I thought it would be a good idea to allow all headers (mostly for debugging purposes). Though the spec do not have any possibilities to 'allow all headers'. They must be listed one by one.
As far as I understand your question you're asking what if sending back all the headers CORS received in Access-Control-Request-Headers. IMHO it would look as a security hole because it undermines the whole idea about 'allowed headers'. I found logging Access-Control-Request-Headers headers which are not allowed to be a better solution for debugging.

[neomerx]

@barryvdh BTW if you think it would be better to send all them back you can easily override it here and here.

Also https://github.com/neomerx/cors-psr7#advanced-usage

If you have any further questions please don't hesitate to ask.