Werkzeug: Werkzeug no conforme a RFC2616

Este comportamiento es causado por la propia especificación WSGI, y es imposible para Werkzeug hacer una distinción entre esos dos encabezados sin dejar de adherirse a la especificación WSGI. No conozco ninguna situación en la que esto haya sido un problema en la práctica.

Por cierto, RFC 2616 está en desuso, pero las nuevas RFC no cambian nada en ese sentido de todos modos.

Además, Werkzeug no es responsable de analizar o escribir solicitudes o respuestas HTTP a nivel sintáctico. Esto lo hace el servidor WSGI que elija. Werkzeug tiene un servidor incorporado, pero eso solo extiende el servidor WSGI de la biblioteca estándar.

El comportamiento no es causado por la especificación WSGI, si se refiere a PEP 3333.
PEP 3333 establece que:
Variables HTTP_
Variables correspondientes a los encabezados de solicitud HTTP proporcionados por el cliente (es decir, variables cuyos nombres comienzan con "HTTP_"). La presencia o ausencia de estas variables debe corresponder con la presencia o ausencia del encabezado HTTP apropiado en la solicitud.

No hay nada en las especificaciones acerca de tratar los subrayados de manera diferente. De hecho, tampoco cumple con PEP 3333 porque no puedo saber qué encabezado está presente o ausente, es decir, si está presente "App_H" o "App-H".

WSGI es un puerto de CGI específico de Python. PEP 0333 hace referencia a la especificación CGI para la definición de "variables de entorno CGI", que establece:

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.

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

Todo esto es irrelevante ya que Werkzeug, en su mayor parte, no analiza las solicitudes HTTP sin procesar y no produce el entorno WSGI. Analiza el entorno WSGI. No veo por qué presenta este problema en contra de esta implementación en particular. No dispares al mensajero.

Básicamente, aquí hay mucho legado de CGI, que es heredado por WSGI, que es lo que Werkzeug está tratando de implementar.

Realmente no es mi intención iniciar una pelea; Pero es un problema con implicaciones de seguridad, especialmente para servidores web que se encuentran detrás de pasarelas de aplicaciones "heredadas" que pasan información sensible / específica de la aplicación en encabezados que contienen guiones bajos sin filtrar otros encabezados (tengo ejemplos concretos, es decir, esto es en realidad un problema en la práctica, que ha descartado con su comentario inicial). CGI tiene más de 20 años, por lo tanto, las especificaciones WSGI y HTTP deben tener prioridad.

En cuanto al análisis sin procesar:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(Tengo ejemplos concretos, es decir, esto es en realidad un problema en la práctica, que ha descartado con su comentario inicial)

Entonces todo lo que puedo decir es que lamento que tenga un servidor como ese. Werkzeug no puede hacer nada al respecto. El fragmento que mostró fue precisamente el motivo por el que dije "en su mayor parte". Werkzeug también incluye un servidor de prueba simple que se puede usar en desarrollo (para evitar tener que configurar Gunicorn + Nginx / Apache, por ejemplo). Pero si está exponiendo ese servidor a Internet, el problema potencial que menciona será el menor de sus problemas (de seguridad).

WSGI fue diseñado para ser compatible con CGI en la mayor medida posible. WSGI no anula ni reemplaza a CGI. WSGI _es_ CGI. Hay muy poco trabajo involucrado en hacer de una aplicación WSGI una aplicación CGI válida. os.environ de un script CGI de Python se parece principalmente al entorno WSGI equivalente. Hay mucho legado a considerar al cambiar algo sobre esto. Werkzeug como proyecto no tiene voz en esto, y menos yo.

Nuevamente, este problema para este proyecto no tiene sentido. Werkzeug no está solo en este comportamiento. La última vez que verifiqué que nginx bloquea los encabezados HTTP con guiones bajos de forma predeterminada, debido a todo el problema de ambigüedad. La mayoría de las otras herramientas probablemente solo las combinen. Si la mayoría de las herramientas no pueden diferenciar entre un guión y un guión bajo, ya no importa cuando el estándar dice que hay uno. Todos se ven obligados a seguir el juego y, finalmente, la herramienta que emite encabezados con guiones bajos es la culpable.