Werkzeug: Werkzeug не соответствует RFC2616

Такое поведение вызвано самой спецификацией WSGI, и Werkzeug не может провести различие между этими двумя заголовками, при этом придерживаясь спецификации WSGI. Я не знаю ни одной ситуации, когда бы это было проблемой на практике.

Кстати, RFC 2616 устарел, но новые RFC в любом случае ничего не меняют в этом отношении.

Также Werkzeug не несет ответственности за синтаксический анализ или запись HTTP-запросов или ответов. Это выполняется любым выбранным вами сервером WSGI. У Werkzeug есть встроенный сервер, но он только расширяет WSGI-сервер из стандартной библиотеки.

Поведение не вызвано спецификацией WSGI, если вы имеете в виду PEP 3333.
PEP 3333 утверждает, что:
HTTP_ переменные
Переменные, соответствующие предоставленным клиентом заголовкам HTTP-запроса (т. Е. Переменные, имена которых начинаются с «HTTP_»). Наличие или отсутствие этих переменных должно соответствовать наличию или отсутствию соответствующего HTTP-заголовка в запросе.

В спецификации нет ничего о другом обращении с подчеркиванием. Фактически, вы не соответствуете PEP 3333, потому что я не могу знать, какой заголовок присутствует или отсутствует, т.е. присутствует ли «App_H» или «App-H».

WSGI - это порт CGI для Python. PEP 0333 ссылается на спецификацию CGI для определения «переменных среды CGI», в которой говорится:

The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has `HTTP_' prepended to give the meta-variable name.

См. Https://tools.ietf.org/html/rfc3875#section -4.1.18.

Все это не имеет значения, поскольку Werkzeug по большей части не анализирует необработанные HTTP-запросы и не создает среду WSGI. Он анализирует среду WSGI. Я не понимаю, почему вы выдвигаете эту проблему против этой конкретной реализации. Не стреляйте в посыльного.

По сути, здесь много наследия CGI, которое унаследовано WSGI, что и пытается реализовать Werkzeug.

Я действительно не хочу начинать драку; Но это проблема с последствиями для безопасности, особенно для веб-серверов, которые находятся за «устаревшими» шлюзами приложений, которые передают конфиденциальную / специфичную для приложения информацию в заголовках, содержащих символы подчеркивания, без фильтрации других заголовков (у меня есть конкретные примеры, то есть это на самом деле проблема на практике, которую вы отклонили своим первоначальным комментарием). CGI более 20 лет, поэтому спецификации WSGI и HTTP должны иметь приоритет.

Что касается сырого парсинга:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(У меня есть конкретные примеры, то есть на самом деле это проблема на практике, которую вы отклонили своим первоначальным комментарием)

Тогда все, что я могу сказать, это то, что мне очень жаль, что у вас есть такой сервер. Werkzeug ничего не может с этим поделать. Именно поэтому я сказал «по большей части» именно тот фрагмент, который вы показали. Werkzeug также включает в себя простой тестовый сервер, который можно использовать в процессе разработки (например, чтобы избежать установки Gunicorn + Nginx / Apache). Но если вы открываете этот сервер в Интернете, потенциальная проблема, о которой вы говорите, будет наименьшей из ваших проблем (безопасности).

WSGI был разработан для максимальной совместимости с CGI. WSGI не отменяет и не заменяет CGI. WSGI _is_ CGI. Чтобы сделать приложение WSGI действительным приложением CGI, требуется очень мало работы. os.environ скрипта Python CGI в основном похож на эквивалентную среду WSGI. При изменении чего-либо в этом отношении необходимо учитывать множество факторов. Werkzeug как проект не имеет права голоса в этом вопросе, особенно я.

Опять же, этот вопрос для этого проекта не имеет смысла. Werkzeug не одинок в таком поведении. В прошлый раз я проверил, что nginx по умолчанию блокирует HTTP-заголовки с подчеркиванием из-за всей проблемы неоднозначности. Большинство других инструментов, вероятно, просто объединяют их. Если большинство инструментов не могут отличить тире от подчеркивания, больше не имеет значения, когда в стандарте указано, что он есть. Все вынуждены подыгрывать, и в конечном итоге виноват инструмент, выдающий заголовки с подчеркиванием.