Werkzeug: Werkzeug entspricht nicht RFC2616

Dieses Verhalten wird durch die WSGI-Spezifikation selbst verursacht, und es ist für Werkzeug unmöglich, zwischen diesen beiden Headern zu unterscheiden, während die WSGI-Spezifikation weiterhin eingehalten wird. Mir ist keine Situation bekannt, in der dies in der Praxis ein Problem war.

RFC 2616 ist übrigens veraltet, aber die neueren RFCs ändern daran sowieso nichts.

Werkzeug ist auch nicht dafür verantwortlich, HTTP-Anfragen oder -Antworten auf syntaktischer Ebene zu analysieren oder zu schreiben. Dies erfolgt durch den von Ihnen gewählten WSGI-Server. Werkzeug hat zwar einen eingebauten Server, der aber nur den WSGI-Server aus der Standardbibliothek erweitert.

Das Verhalten wird nicht durch die WSGI-Spezifikation verursacht, wenn Sie sich auf PEP 3333 beziehen.
PEP 3333 besagt, dass:
HTTP_-Variablen
Variablen, die den vom Client bereitgestellten HTTP-Anforderungsheadern entsprechen (dh Variablen, deren Namen mit "HTTP_" beginnen). Das Vorhandensein oder Fehlen dieser Variablen sollte dem Vorhandensein oder Fehlen des entsprechenden HTTP-Headers in der Anfrage entsprechen.

In der Spezifikation steht nichts über die unterschiedliche Behandlung von Unterstrichen. Tatsächlich entsprechen Sie auch nicht PEP 3333, weil ich nicht wissen kann, welcher Header vorhanden oder nicht vorhanden ist, dh ob "App_H" oder "App-H" vorhanden ist.

WSGI ist eine Python-spezifische Portierung von CGI. PEP 0333 verweist auf die CGI-Spezifikation für die Definition von "CGI-Umgebungsvariablen", die besagt:

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.

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

All dies ist irrelevant, da Werkzeug größtenteils keine rohen HTTP-Anforderungen analysiert und keine WSGI-Umgebung erstellt. Es analysiert die WSGI-Umgebung. Ich verstehe nicht, warum Sie dieses Problem gegen diese spezielle Implementierung einreichen. Erschieße den Boten nicht.

Im Grunde gibt es hier viel Vermächtnis von CGI, das von WSGI geerbt wird, was Werkzeug zu implementieren versucht.

Ich will wirklich keinen Streit anfangen; Aber es ist ein Problem mit Sicherheitsauswirkungen, insbesondere für Webserver, die hinter "alten" Anwendungs-Gateways sitzen, die sensible / anwendungsspezifische Informationen in Headern mit Unterstrichen übergeben, ohne andere Header zu filtern (ich habe konkrete Beispiele, das heißt, das ist tatsächlich ein Problem in der Praxis, das Sie mit Ihrem ersten Kommentar abgetan haben). CGI ist über 20 Jahre alt, daher sollten WSGI- und HTTP-Spezifikationen Vorrang haben.

Was das Rohparsing angeht:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(Ich habe konkrete Beispiele, d.h. es handelt sich tatsächlich um ein Thema in der Praxis, das Sie mit Ihrem ersten Kommentar abgetan haben)

Dann kann ich nur sagen, dass es mir leid tut, dass Sie so einen Server haben. Werkzeug kann nichts dagegen tun. Der Ausschnitt, den Sie gezeigt haben, war genau der Grund, warum ich "größtenteils" sagte. Werkzeug enthält auch einen einfachen Testserver, der in der Entwicklung verwendet werden kann (um beispielsweise Gunicorn + Nginx/Apache nicht einrichten zu müssen). Wenn Sie diesen Server jedoch dem Internet aussetzen, ist das potenzielle Problem, das Sie erwähnen, das geringste Ihrer (Sicherheits-)Probleme.

WSGI wurde so konzipiert, dass es so weit wie möglich mit CGI kompatibel ist. WSGI überschreibt oder ersetzt CGI nicht. WSGI _ist_ CGI. Es ist nur sehr wenig Arbeit erforderlich, um eine WSGI-Anwendung zu einer gültigen CGI-Anwendung zu machen. os.environ eines Python-CGI-Skripts sieht größtenteils wie die entsprechende WSGI-Umgebung aus. Es gibt eine Menge Erbe zu berücksichtigen, wenn etwas daran geändert wird. Werkzeug als Projekt hat da kein Mitspracherecht und schon gar nicht ich.

Auch dieses Thema für dieses Projekt ist sinnlos. Werkzeug ist mit diesem Verhalten nicht allein. Als ich das letzte Mal überprüft habe, dass nginx HTTP-Header standardmäßig mit Unterstrichen blockiert, aufgrund des gesamten Mehrdeutigkeitsproblems. Die meisten anderen Tools vermischen sie wahrscheinlich nur. Wenn die meisten Tools den Unterschied zwischen einem Bindestrich und einem Unterstrich nicht erkennen können, spielt es keine Rolle mehr, wann der Standard einen solchen vorsieht. Jeder ist gezwungen, mitzuspielen, und schließlich ist das Tool schuld, das Kopfzeilen mit Unterstrichen ausgibt.