La nginx consente a un server upstream di rispondere e chiudere una richiesta prima di terminare?

Ho un servizio di caricamento di immagini che richiede i proxy di nginx. Tutto funziona bene. A volte tuttavia, il server ha già l'image che l'utente sta caricando. Quindi, voglio rispondere presto e chiudere la connessione.

Dopo aver letto le intestazioni e controllando con il server, chiamo il response.end di Node ([data] [, codifica] [, callback]) .

  • Nginx serve file statici e cambia path / path
  • Come posso utilizzare i caratteri jolly in una direttiva mappa Nginx?
  • Salva il stream ai file mp4
  • Scomposizione di lunghe righe in un file di configuration nginx
  • Come faccio a dire a Nginx di aspettare alcuni secondi prima di servire un asset?
  • Perché sub_filter sembra non funzionare se utilizzato in combinazione con proxy_pass?
  • Nginx barfs e restituisce una risposta vuota:

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

    La mia ipotesi è che nginx presume che qualcosa di brutto è accaduto nel server upstream, scarta immediatamente la connessione client senza submit la risposta del server upstream.

    Qualcuno sa come rispondere correttamente e chiudere la connessione del cliente quando nginx è il proxy? So che questo è ansible: vedi: invio della risposta prima che la richiesta sia stata inserita

    Ecco il file confl nginx:

     worker_processes 8; # the number of processrs 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; } 

  • Ascolta l'alternativa Nginx
  • Nginx come proxy inverso che serve HTTPS
  • Amazon EC2 - No SSH Dopo il riavvio, la connessione è rifiutata
  • la mia prima configuration del server debian "di produzione"
  • Nginx (openrest) che genera numbers casuali
  • Come devo strutturare i miei utenti / gruppi / autorizzazioni per un server web?
  • One Solution collect form web for “La nginx consente a un server upstream di rispondere e chiudere una richiesta prima di terminare?”

    Non si menziona ciò che i tuoi clienti sono, tuttavia, questo suona come qualcosa che si otterrebbe con un'intestazione aspetta. In sostanza, il client imposta un'intestazione "Expect" con un'attesa "100-continue". Il client attende quindi una risposta 100 Continua dal server, prima di submit il suo corpo di richiesta.

    Se il server non desidera ricevere il corpo, può rispondere con uno stato finale e il client non invia il corpo.

    Questo process è definito in RFC2616, sezione 8.2.3

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.