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]) .

  • Il server Nginx + SSL non risponde
  • Combina diverse località con regex in nginx
  • Uso di nginx per riscrivere URL all'interno delle risposte in output
  • Permesso nginx negato ai file di certificazione per la configuration ssl
  • nginx HTTPS WWW redirect a non-WWW
  • Imansible accedere a https nonostante la port 443 sia aperta
  • 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; } 

  • Hosting cartella nella home directory usando nginx
  • lunga password SSH vs chiavi SSH
  • NGINX 'posizione globale'
  • Mono su Linux: Apache o Nginx
  • SSH non richiede la password, dà immediatamente "authorization negata"
  • Buffer richiede nginx per un breve periodo se il backend è in discesa
  • 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.