Ответ 1
Документация по этому вопросу, по-видимому, подразумевает, что она допускает множественное происхождение с разделенным пробелом списком, но это не то, что на самом деле означает. Вот что я мог бы получить в качестве наиболее окончательного ответа на ваш вопрос: заголовок Access-Control-Allow-Origin должен быть таким же значением, что и заголовок Origin, если вы хотите его разрешить.
Причина, по которой он не является белым списком, который вы отправляете обратно клиенту, заключается в том, что по техническим причинам клиент может отправить список источников, разделенных пробелами, чтобы сервер мог проверить запрос. Назначение списка происхождения тогда состоит в том, что запрос мог быть получен из нескольких источников (т.е. Запрос был перенаправлен по доменам). Набор тестов позволяет легко наблюдать это поведение с различными возможностями переадресации, даже если список, разделенный пробелом, никогда не создается (по крайней мере, Firefox).
Это показано ниже в первом связанном документе W3C, который вы предоставили:
Заголовок Access-Control-Allow-Origin указывает, может ли ресурс делиться на основе возврата значения заголовка запроса Origin, "*" или "null" в ответе. ABNF:
Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"
На практике производство origin-list-or-null более ограничено. Вместо того, чтобы разрешать список источников, разделенных пробелами, это либо одно происхождение, либо строка "null" .
И снова в определение списка происхождения. Кроме того, он показывает, хотите ли вы разрешить строку "null" в качестве источника, в любом случае она не сможет быть включена в список происхождения.
Итак, придерживайтесь динамически сгенерированного заголовка на основе клиентского Origin заголовка и соответствует ли ваш белый список.