web-dev-qa-db-ja.com

nginxは、アップストリームサーバーが要求に応答して、要求が完了する前に閉じることを許可しますか?

Nginxプロキシがリクエストする画像アップロードサービスがあります。すべてがうまく機能します。ただし、サーバーには、ユーザーがアップロードしている画像が既にある場合があります。だから、早く対応して接続を閉じたい。

ヘッダーを読み取ってサーバーに確認した後、ノードの response.end([data] [、encoding] [、callback]) を呼び出します。

Nginxはbarfsし、空白の応答を返します:

[error] 3831#0: *12879 readv() failed (104: Connection reset by peer) while reading upstream

私の推測では、nginxはアップストリームサーバーで何か問題が発生したと想定し、アップストリームサーバーの応答を送信せずにクライアント接続をすぐに切断します。

Nginxがプロキシである場合に、クライアントの接続に適切に応答して閉じる方法を知っている人はいますか?私はこれが可能であることを知っています: 参照:要求が入る前に応答を送信する

これがnginxconfファイルです:

worker_processes 8; # the number of processors
worker_rlimit_nofile 128; # each connection needs 2 file handles

events {
  worker_connections 128; # two connections per end-user connection (proxy)
  multi_accept on;
  use kqueue;
}

http {
  sendfile on;
  tcp_nopush on; # attempt to send HTTP response head in one packet
  tcp_nodelay off; # Nagle algorithm, wait until we have the maximum amount of data the network can send at once
  keepalive_timeout 65s;

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

  error_log /usr/local/var/log/nginx/error.log;
  log_format main '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  gzip off;

}

upstream upload_service {
  server 127.0.0.1:1337 fail_timeout=0;
  keepalive 64;
}

location /api/upload_service/ {
  # setup proxy to UpNode
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Host $http_Host;
  proxy_set_header X-NginX-Proxy true;
  proxy_set_header Connection "";
  proxy_pass http://upload_service;

  # The timeout is set only between two successive read operations
  proxy_read_timeout 500s;
  # timeout for reading client request body, only for a period between two successive read   operations
  client_body_timeout 30s;
  # maximum allowed size of the client request body, specified in the "Content-Length"
  client_max_body_size 64M;
}
6
thesmart

クライアントが何であるかについては言及していませんが、これは、expectヘッダーを使用して達成できることのように聞こえます。本質的に、クライアントは「100-continue」期待値で「Expect」ヘッダーを設定します。次に、クライアントは、要求本文を送信する前に、サーバーからの100Continue応答を待ちます。

サーバーが本文を受信したくない場合、サーバーは最終ステータスで応答でき、クライアントは本文を送信しません。

このプロセスは RFC2616、セクション8.2. で定義されています。

2
ColtonCat