Werkzeug: Werkzeug não está em conformidade com RFC2616

Esse comportamento é causado pela própria especificação WSGI e é impossível para Werkzeug fazer uma distinção entre esses dois cabeçalhos enquanto segue a especificação WSGI. Não conheço nenhuma situação em que isso tenha sido um problema na prática.

A propósito, o RFC 2616 está obsoleto, mas os RFCs mais recentes não mudam nada a esse respeito.

Além disso, Werkzeug não é responsável por analisar ou gravar solicitações ou respostas HTTP em um nível sintático. Isso é feito por qualquer servidor WSGI que você escolher. Werkzeug tem um servidor embutido, mas isso apenas estende o servidor WSGI da biblioteca padrão.

O comportamento não é causado pela especificação WSGI, se você estiver se referindo ao PEP 3333.
PEP 3333 afirma que:
HTTP_ Variables
Variáveis ​​correspondentes aos cabeçalhos de solicitação HTTP fornecidos pelo cliente (ou seja, variáveis ​​cujos nomes começam com "HTTP_"). A presença ou ausência dessas variáveis ​​deve corresponder à presença ou ausência do cabeçalho HTTP apropriado na solicitação.

Não há nada nas especificações sobre o tratamento de sublinhados de maneira diferente. Na verdade, você não está em conformidade com o PEP 3333 porque não posso saber qual cabeçalho está presente ou ausente, ou seja, se "App_H" ou "App-H" está presente.

WSGI é uma porta de CGI específica para Python. PEP 0333 faz referência à especificação CGI para a definição de "variáveis ​​de ambiente CGI", que afirma:

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.

Consulte https://tools.ietf.org/html/rfc3875#section -4.1.18

Tudo isso é irrelevante, pois Werkzeug, na maior parte, não analisa solicitações HTTP brutas e não produz o ambiente WSGI. Ele analisa o ambiente WSGI. Não vejo por que você está apresentando esse problema com essa implementação específica. Não atire no mensageiro.

Basicamente, há muito legado de CGI aqui, que é herdado por WSGI, que é o que Werkzeug está tentando implementar.

Eu realmente não quero começar uma briga; Mas é um problema com implicações de segurança, especialmente para servidores web que ficam atrás de gateways de aplicativos "legados" -ish que passam informações confidenciais / específicas do aplicativo em cabeçalhos contendo sublinhados sem filtrar outros cabeçalhos (eu tenho exemplos concretos, isto é, na verdade, um problema na prática, que você descartou com seu comentário inicial). CGI tem mais de 20 anos, portanto, as especificações WSGI e HTTP devem ter precedência.

Quanto à análise bruta:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(Eu tenho exemplos concretos, isto é, este é realmente um problema na prática, que você descartou com seu comentário inicial)

Então, tudo o que posso dizer é que sinto muito por você ter um servidor como esse. Werkzeug não pode fazer nada a respeito. O trecho que você mostrou foi exatamente o motivo pelo qual eu disse "na maior parte". Werkzeug também inclui um servidor de teste simples que pode ser usado no desenvolvimento (para evitar ter que configurar Gunicorn + Nginx / Apache, por exemplo). Mas se você está expondo esse servidor à Internet, o problema potencial que você mencionou será o menor dos seus problemas (de segurança).

WSGI foi projetado para ser compatível com CGI na medida do possível. WSGI não substitui ou substitui CGI. WSGI _is_ CGI. Há muito pouco trabalho envolvido em tornar um aplicativo WSGI um aplicativo CGI válido. os.environ de um script Python CGI se parece principalmente com o ambiente WSGI equivalente. Há muito legado a ser considerado ao mudar qualquer coisa sobre isso. Werkzeug como um projeto não tem nada a dizer sobre isso, especialmente eu.

Novamente, esse problema para este projeto é inútil. Werkzeug não está sozinho nesse comportamento. A última vez que verifiquei nginx bloqueia cabeçalhos HTTP com sublinhados por padrão, devido a todo o problema de ambigüidade. A maioria das outras ferramentas provavelmente apenas os confunde. Se a maioria das ferramentas não consegue diferenciar um traço e um sublinhado, não importa mais quando o padrão diz que existe um. Todos são forçados a jogar junto e, eventualmente, a culpa é da ferramenta que emite cabeçalhos com sublinhados.