Werkzeug: Werkzeug가 RFC2616을 준수하지 않음

이 동작은 WSGI 사양 자체로 인해 발생하며 Werkzeug가 WSGI 사양을 계속 준수하면서 두 헤더를 구분하는 것은 불가능합니다. 이것이 실제로 문제가 된 상황에 대해 알지 못합니다.

그런데 RFC 2616은 더 이상 사용되지 않지만 최신 RFC는 어쨌든 이와 관련하여 아무 것도 변경하지 않습니다.

또한 Werkzeug는 구문 수준에서 HTTP 요청 또는 응답을 구문 분석하거나 작성하는 데 책임이 없습니다. 이것은 선택한 WSGI 서버에 의해 수행됩니다. Werkzeug에는 내장 서버가 있지만 이는 표준 라이브러리의 WSGI 서버만 확장합니다.

PEP 3333을 참조하는 경우 이 동작은 WSGI 사양으로 인해 발생하지 않습니다.
PEP 3333은 다음과 같이 말합니다.
HTTP_ 변수
클라이언트 제공 HTTP 요청 헤더에 해당하는 변수(즉, 이름이 "HTTP_"로 시작하는 변수). 이러한 변수의 존재 또는 부재는 요청에 적절한 HTTP 헤더의 존재 또는 부재와 일치해야 합니다.

사양에는 밑줄을 다르게 처리하는 것에 대한 내용이 없습니다. 사실, "App_H" 또는 "App-H"가 있는지 여부와 같이 어떤 헤더가 있는지 또는 없는지 알 수 없기 때문에 PEP 3333을 준수하지 않습니다.

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 환경을 구문 분석합니다. 이 특정 구현에 대해 이 문제를 제기하는 이유를 모르겠습니다. 메신저를 쏘지 마세요.

기본적으로 여기에는 Werkzeug가 구현하려고 하는 WSGI에 의해 상속된 CGI의 많은 유산이 있습니다.

나는 정말로 싸움을 시작하려는 것이 아닙니다. 그러나 다른 헤더를 필터링하지 않고 밑줄이 포함된 헤더에 민감한/애플리케이션 특정 정보를 전달하는 "레거시" 애플리케이션 게이트웨이 뒤에 있는 웹 서버의 경우 특히 보안 관련 문제가 있습니다(구체적인 예가 있습니다. 실제로 실제로 문제이며 초기 의견으로 기각했습니다). 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 헤더를 차단합니다. 대부분의 다른 도구는 아마도 그것들을 합칠 것입니다. 대부분의 도구가 대시와 밑줄의 차이를 구분할 수 없다면 표준에 하나가 있다고 해도 더 이상 중요하지 않습니다. 모두가 함께 플레이해야 하며, 결국 밑줄이 있는 헤더를 내보내는 도구가 책임이 있습니다.