nginx télécharger client_max_body_size problème

Question

Je suis en cours d'exécution nginx/ruby-on-rails et j'ai un simple formulaire multipart de téléchargement de fichiers. Tout fonctionne bien jusqu'à ce que je décide de limiter la taille maximale des fichiers que je veut télécharger. Pour ce faire, j'ai mis la nginx client_max_body_size de 1m (1 MO) et de s'attendre à une HTTP 413 (Entité de Demande Trop Grande) d'état en réponse lorsque cette règle pauses.

Le problème est que quand je télécharge un 1.2 MO de fichier, au lieu d'afficher le HTTP 413 page d'erreur, le navigateur se bloque un peu, puis meurt avec une "Connexion a été réinitialisée pendant chargement de la page" message.

J'ai essayé à peu près toutes les options il n'y a que nginx offre, rien ne semble fonctionner. Quelqu'un aurait-il une idée à ce propos?

Voici mon 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;    
    }    
}

Merci.

---

**Edit**

Environnement/UA: Windows XP/Firefox 3.6.13

Answer 1

nginx "échoue rapide" quand le client l'informe qu'il va envoyer un corps plus gros que l' client_max_body_size par l'envoi d'un 413 réponse et la fermeture de la connexion.

La plupart des clients ne lisent pas les réponses jusqu'à ce que l'ensemble du corps de la requête est envoyée. Parce que nginx ferme la connexion, le client envoie des données à la socket fermée, provoquant un paquet TCP RST.

Si votre client HTTP soutient-il, la meilleure façon de gérer cela est d'envoyer un Expect: 100-Continue - tête. Nginx prend en charge correctement comme des 1.2.7, et répond avec un 413 Request Entity Too Large de réponse plutôt que d' 100 Continue si Content-Length dépasse le maximum de la taille du corps.

Answer 2

Votre téléchargement de mourir à la fin? 99% avant de s'écraser? Client du corps et les tampons sont essentiels parce que nginx doit tampon des données entrantes. Le corps configs (données du corps de la requête) spécifier comment nginx gère la majeure partie des flux de données binaires à partir de multi-partie-forme clients dans votre application logique. Le propre réglage de libérer de la mémoire et les limites de consommation en donnant l'ordre de nginx pour stocker entrant tampon dans un fichier et de le nettoyer ce fichier plus tard à partir du disque en le supprimant. Ensemble body_in_file_only à nettoyer et ajuster les tampons pour la client_max_body_size. La question d'origine de la config déjà eu sendfile, augmentation des délais d'attente trop. J'ai utiliser les paramètres ci-dessous pour résoudre ce problème, appropriée à l'échelle de votre local de la configuration du serveur, et de http contextes.

client_body_in_file_only clean;
client_body_buffer_size 32K;

client_max_body_size 300M;

sendfile on;
send_timeout 300s;

Answer 3

À partir de la documentation:

Il est nécessaire de garder à l'esprit que les navigateurs ne sais pas comment faire pour afficher correctement cette erreur.

Je suppose que c'est ce qui se passe, si vous examinez les HTTP-et-vient à l'aide d'outils comme Firebug ou Live HTTP Headers (les deux extensions Firefox), vous serez en mesure de voir ce qui se passe réellement.

Answer 4

Le fichier /the_root/413.html existent-ils? C'est là que Nginx est à la recherche pour le fichier à afficher.

Vérifiez également les Nginx erreur.journal.

Answer 5

Nous avons traité de la question par l'envoi de la requête post via ajax.