나는 파일 업로드를 처리하는 가장 좋은 방법을 이해하기 위해 노력하고있다. 안전하게을 wsgi 응용 프로그램에서 사용하고있다. cgi 모듈에서 FieldStorage를 사용하여 양식 데이터를 구문 분석하는 것과 관련된 많은 솔루션이있는 것 같습니다. 필자가 FieldStorage에 대해 알고있는 것으로부터, 임시 파일에 데이터를 스트리밍함으로써 장면의 뒤에서 약간의 '마법'을 수행합니다.wsgi에서 대용량 파일 업로드를 어떻게 제한합니까?
내가 100 % 명확하지 않은 것은 지정된 양 (예 : 10MB)을 초과하는 파일을 포함하는 요청을 제한하는 방법입니다. 누군가가 크기가 몇 GB 인 파일을 업로드하면 서버의 디스크 공간을 씹기 전에 분명히 요청을 차단하고 싶습니까?
wsgi 응용 프로그램에서 파일 업로드를 제한하는 가장 좋은 방법은 무엇입니까?
프런트 엔드 서버에 따라 다릅니다. 앱에 들어가기 전에 큰 요청을 차단하는 설정이 있다면 사용하십시오.
나는 두 가지 방법을 참조하십시오. 처리 할 수있는 것보다 더 큰 경우 즉시 요청을 거부하십시오.
HTTP 헤더를 신뢰하면 몇 가지 문제가 발생할 수 있습니다. 일부는 Content-Length : 1024로 요청을 보내지 만 1GB 요청 본문을 보냅니다. 프런트 엔드 서버가 헤더를 트러스트하면이 요청을 읽는 것으로 시작하고 나중에 요청 본문이 실제로는 훨씬 커야합니다. 이 상황은 서버 디스크를 채울 수 있습니다. "너무 큰 검사"를 "통과"하는 요청 인 경우에도 마찬가지입니다.
비록 이런 일이 발생할 수 있지만 헤더를 신뢰하는 것이 좋은 출발점이 될 것이라고 생각합니다.
HTTP 서버가 잘못된 'Content-Length' 상황을 처리하면 안됩니까? HTTP/1.1 호환 구현은 추가 콘텐츠를 거부해야한다고 생각했습니다. 게다가 그들은 HTTP keep alive를 구현하기를 원할 때 이것을해야합니다. 그렇지 않으면 다음 요청이 언제 시작되는지 알 수 없습니다. –
네 말이 맞아! 그러나 어쨌든 요청이 Content-Length 헤더의 값보다 실제로 더 큰지 알아내는 것은 까다로울 수 있습니다. 서브는 Content-Length + 1 바이트에 도달 할 때까지 요청을 읽어야하지만, 더 똑똑한 방법이있을 수 있습니다. –
서버는 헤더를 추출하고 요청 본문을 소켓에서 WSGI 응용 프로그램으로 전달해야하므로 요청을 이미 읽고 있습니다. 또한 서버는 HTTP/1.1로 주장 할 수 없습니다. 수표를 발행하지 않으면이를 준수해야합니다. –
WSGI 응용 프로그램 앞에있을 가능성이있는 HTTP 서버의 기능을 사용할 수 있습니다. 예를 들어 lighttpd는 many options for traffic shaping입니다.
이 질문은 'wsgi'태그가 지정되어 있습니다. WSGI 인터페이스를 직접 사용하고 있습니까? 그렇다면'environ [ 'wsgi.input']'에서 읽은 데이터의 양을 제어하고 ('Content-Length' 헤더를 확인하는 것) 케이크 조각이어야합니다. –