nginx 업로드 client_max_body_size 문제

nginx / ruby-on-rails를 실행 중이며 파일을 업로드하는 간단한 멀티 파트 양식이 있습니다. 업로드하려는 파일의 최대 크기를 제한하기 전까지는 모든 것이 잘 작동합니다. 이를 위해 nginx client_max_body_size를 1m (1MB) 로 설정하고 해당 규칙이 위반 될 때 응답으로 HTTP 413 (Request Entity Too Large) 상태를 예상합니다.

문제 는 1.2MB 파일을 업로드 할 때 HTTP 413 오류 페이지를 표시하는 대신 브라우저가 약간 멈춘 다음 "페이지를로드하는 동안 연결이 재설정되었습니다"라는 메시지와 함께 죽는다는 것입니다.

나는 nginx가 제공하는 모든 옵션을 시도했지만 아무것도 작동하지 않는 것 같습니다. 누구든지 이것에 대한 아이디어가 있습니까?

내 nginx.conf는 다음과 같습니다.

worker_processes  1;
timer_resolution  1000ms;
events {
    worker_connections  1024;
}

http {
    passenger_root /the_passenger_root;
    passenger_ruby /the_ruby;

    include       mime.types;
    default_type  application/octet-stream;

    sendfile           on;
    keepalive_timeout  65;

    server {
      listen 80;
      server_name www.x.com;
      client_max_body_size 1M;
      passenger_use_global_queue on;
      root /the_root;
      passenger_enabled on;

      error_page 404 /404.html;
      error_page 413 /413.html;    
    }    
}

감사.

**Edit**

환경 / UA : Windows XP / Firefox 3.6.13

nginx는 클라이언트가 client_max_body_size413 응답을 보내고 연결을 닫음으로써 보다 큰 본문을 보낼 것이라고 알릴 때 "빠르게 실패"합니다 .

대부분의 클라이언트는 전체 요청 본문이 전송 될 때까지 응답을 읽지 않습니다. nginx가 연결을 닫기 때문에 클라이언트는 닫힌 소켓으로 데이터를 보내 TCP RST를 발생시킵니다.

HTTP 클라이언트가이를 지원하는 경우이를 처리하는 가장 좋은 방법은 Expect: 100-Continue헤더 를 보내는 것 입니다. Nginx에 제대로 1.2.7 현재 동을 지원하고, 회신 것 413 Request Entity Too Large보다는 응답 100 Continue하는 경우 Content-Length최대 몸 크기를 초과합니다.

업로드가 끝날 때 죽습니까? 충돌하기 전에 99 %? nginx는 들어오는 데이터를 버퍼링해야하므로 클라이언트 본문과 버퍼가 핵심입니다. 본문 구성 (요청 본문의 데이터)은 nginx가 다중 파트 양식 클라이언트에서 앱 논리로의 바이너리 데이터 대량 흐름을 처리하는 방법을 지정합니다.

이 clean설정은 nginx가 들어오는 버퍼를 파일에 저장하고 나중에이 파일을 삭제하여 디스크에서 정리하도록 지시하여 메모리 및 소비 제한을 해제합니다.

설정 body_in_file_only에 clean와에 대한 버퍼를 조정합니다 client_max_body_size. 원래 질문의 구성에는 이미 sendfile이 설정되어 있으므로 시간 초과도 증가합니다. 아래 설정을 사용하여 로컬 구성, 서버 및 http 컨텍스트에서 적절하게 수정합니다.

client_body_in_file_only clean;
client_body_buffer_size 32K;

client_max_body_size 300M;

sendfile on;
send_timeout 300s;

에서 문서 :

브라우저는이 오류를 올바르게 표시하는 방법을 모른다는 점을 염두에 두어야합니다.

다음과 같은 도구를 사용하여 HTTP를 앞뒤로 검사하면 이것이 일어나는 일이라고 생각합니다. Firebug 또는 Live HTTP Headers (두 파이어 폭스 확장) 실제로 무슨 일이 일어나고 있는지 확인할 수 있습니다.