Une redirection vers une page d'erreur sans explication

Question

J'ai une application rails, où les utilisateurs peuvent télécharger des fichiers (en utilisant paperclip). Lors du téléchargement de fichiers volumineux, l'utilisateur est redirigé vers une page d'erreur 500, ce qui se produit uniquement à distance. localement, l'utilisateur est redirigé vers la vue du nouveau modèle, comme prévu. De plus, malgré la redirection de la page d'erreur, le modèle et son fichier associé ont été téléchargés et créés avec succès.

Comme cela se produit uniquement avec des fichiers volumineux, je suppose que cela est dû à un délai d'attente de demande, mais j'utilise puma qui doesn't enforce such timeouts.

C'est le journal des applications, les journaux puma ne montrent rien d'anormal.

D, DEBUG -- : SQL (0.4ms) INSERT INTO "posts" [...] 
D, DEBUG -- : (0.9ms) COMMIT 
D, DEBUG -- : (0.1ms) BEGIN 
D, DEBUG -- : (0.1ms) COMMIT 
I, INFO -- : Started GET "/500.html" for [...] 
F, FATAL -- : 
ActionController::RoutingError (No route matches [GET] "/500.html"): 
    actionpack (4.2.6) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call' 
    actionpack (4.2.6) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call' 
    railties (4.2.6) lib/rails/rack/logger.rb:38:in `call_app' 
    railties (4.2.6) lib/rails/rack/logger.rb:20:in `block in call' 
    activesupport (4.2.6) lib/active_support/tagged_logging.rb:68:in `block in tagged' 
    activesupport (4.2.6) lib/active_support/tagged_logging.rb:26:in `tagged' 
    activesupport (4.2.6) lib/active_support/tagged_logging.rb:68:in `tagged' 
    railties (4.2.6) lib/rails/rack/logger.rb:20:in `call' 
    actionpack (4.2.6) lib/action_dispatch/middleware/request_id.rb:21:in `call' 
    rack (1.6.4) lib/rack/methodoverride.rb:22:in `call' 
    rack (1.6.4) lib/rack/runtime.rb:18:in `call' 
    activesupport (4.2.6) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call' 
    rack (1.6.4) lib/rack/sendfile.rb:113:in `call' 
    railties (4.2.6) lib/rails/engine.rb:518:in `call' 
    railties (4.2.6) lib/rails/application.rb:165:in `call' 
    puma (3.6.0) lib/puma/configuration.rb:225:in `call' 
    puma (3.6.0) lib/puma/server.rb:578:in `handle_request' 
    puma (3.6.0) lib/puma/server.rb:415:in `process_client' 
    puma (3.6.0) lib/puma/server.rb:275:in `block in run' 
    puma (3.6.0) lib/puma/thread_pool.rb:116:in `block in spawn_thread' 

Answer 1

J'ai trouvé une réponse dans le journal nginx: il était en effet un délai d'attente. Augmenter proxy_read_timeout dans nginx.conf résolu le problème (la valeur par défaut est 60).