web-dev-qa-db-fra.com

net :: ERR_CONNECTION_RESET lorsqu'un fichier volumineux prend plus d'une minute

J'ai un téléchargement de fichier en plusieurs parties sous une forme avec un backend php. J'ai mis max_execution_time et max_input_time dans php.ini à 180 et confirmé lors du téléchargement du fichier que ces valeurs sont définies et définissez TimeOut 180 dans Apache. J'ai aussi mis

RewriteRule .* - [E=noabort:1]
RewriteRule .* - [E=noconntimeout:1]

Lorsque je télécharge un fichier de 250 Mo sur une connexion rapide, cela fonctionne bien. Lorsque je suis sur une connexion plus lente ou un conditionneur de liaison réseau pour le ralentir artificiellement, le même fichier expire et s'allume Chrome me donne net::ERR_CONNECTION_RESET après 1 minute (et 5 secondes) de manière fiable. J'ai également essayé d'autres navigateurs avec le même résultat, juste des messages d'erreur différents.

Il n'y a aucune indication d'une erreur dans un journal et j'ai essayé à la fois sur http et https.

Qu'est-ce qui entraînerait la réinitialisation de la connexion de téléchargement après 1 minute?

MODIFIER

J'ai maintenant également essayé d'avoir un formulaire de téléchargement simple qui contourne tout cadre que j'utilise, toujours des délais d'attente à 1 minute.

Je viens également de créer un script de veille qui expire après 2 minutes et demie, et cela fonctionne, la page prend environ 2,5 minutes à charger, donc je ne peux pas voir comment il est lié au navigateur ou à l'en-tête.

J'ai également utilisé un serveur avec plus RAM pour m'assurer qu'il n'est pas lié à cela. J'ai testé sur 3 serveurs différents avec des spécifications différentes mais tous à partir de la même base CentOS 7.

J'ai maintenant également mis à niveau vers PHP 7.2 et mis à jour les champs pertinents à nouveau sans changement dans le problème.

EDIT 2 La pile technologique de cette instance isolée est

  • Apache 2.4.6
  • PHP 5.6/7.2 (essayé les deux), a OPCache
  • Redis 3.2.6 pour les informations de session et le stockage clé/valeur (ElastiCache)
  • PostgreSQL 10.2 (RDS)

Tout le reste de ma pile technologique a été supprimé de cette zone de test pour essayer d'isoler le problème. EFS est sur le système mais dans mon test le plus isolé, il utilise simplement EBS.

EDIT Voici quelques journaux du débogueur réseau chrome:

{"params":{"net_error":-101,"os_error":32},"phase":0,"source":    {"id":274043,"type":8},"time":"3332701830","type":69},
{"params":    {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":216,"net_error":-101,"ssl_error":1},"phase":0,"source":        {"id":274043,"type":8},"time":"3332701830","type":56},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":159},
{"phase":1,"source":    {"id":274038,"type":1},"time":"3332701830","type":164},
{"phase":1,"source":    {"id":274038,"type":1},"time":"3332701830","type":287},
{"params":    {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":113,"net_error":-101,"ssl_error":1},"phase":0,"source":    {"id":274043,"type":8},"time":"3332701830","type":55},
{"params":{"net_error":-101},"phase":2,"source":    {"id":274038,"type":1},"time":"3332701830","type":287},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":164},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":97},
{"phase":1,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":34},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":2},
phpapachefile-upload
11
Rudiger

J'ai rencontré un problème similaire, dans mon cas, il était lié à mod_reqtimeout en ajoutant:

RequestReadTimeout header=20-40, MinRate=500 body=20, MinRate=500

à httpd.conf a fait l'affaire! Vous pouvez consulter la documentation ici .

J'espère que ça aide!

5
Raul

ERR_CONNECTION_RESET signifie généralement que la connexion au serveur a cessé sans envoyer de réponse au client. Cela signifie que l'ensemble du processus PHP est mort sans pouvoir s'arrêter correctement.

Ceci n'est généralement pas causé par quelque chose comme un exceeded memory_limit. Cela pourrait être une sorte de défaut de segmentation ou quelque chose comme ça. Si vous avez accès aux journaux d'erreurs, vérifiez-les. Sinon, vous pourriez obtenir le support de votre hébergeur.

Je vous recommande d'essayer certaines de ces choses:

1) Essayez de nettoyer le cache du navigateur. Si vous avez déjà visité la page, il est possible que le cache contienne des informations qui ne correspondent pas à la version actuelle du site Web et bloque ainsi la configuration de la connexion, faisant apparaître le message ERR_CONNECTION_RESET.

2) Ajoutez les éléments suivants à vos paramètres:

memory_limit = 1024M

max_input_vars = 2000

upload_max_filesize = 300M

post_max_size = 300M

max_execution_time = 990

3) Essayez de définir l'entrée suivante dans votre formulaire:

<input type="hidden" name="MAX_FILE_SIZE" value="300000000" />

4) Dans votre script de traitement, augmentez le timeout de session:

set_time_limit(200);

5) Vous devrez peut-être régler la taille du tampon SSL dans votre fichier de configuration Apache.

SSLRenegBufferSize 10486000

Le nom et l'emplacement du fichier conf sont différents selon les distributions.

Dans Debian, vous trouverez le fichier conf dans /etc/Apache2/sites-available/default-ssl.conf

6) Quelques fois c'est mod_security module ce qui empêche la publication de données volumineuses d'environ 171 Ko. Essayez d'ajouter/de modifier les éléments suivants dans mod_security.conf

SecRequestBodyNoFilesLimit 10486000
SecRequestBodyInMemoryLimit 10486000

J'espère que quelque chose pourrait marcher!

4
Vikas Yadav

J'ai eu le même problème. J'ai utilisé la méthode de téléchargement de fichiers pouvant être repris où, si Internet est déconnecté et se reconnecte, le téléchargement reprend à partir de la même progression.

Consultez la bibliothèque https://packagist.org/packages/pion/laravel-chunk-upload

  1. Installation

composer require pion/laravel-chunk-upload

  1. Ajouter un fournisseur de services

\Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider::class

  1. Publier la config

php artisan vendor:publish --provider="Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider"

1
murtuza hussain

À mon avis, cela peut être relatif à l'un d'eux:

À propos Apache config (/etc/httpd2/conf ou /etc/Apache2/conf):

Timeout 300
max_execution_time = 300

À propos de php config ('php.ini'):

upload_max_filesize = 2000M
post_max_size = 2000M
max_input_time = 300
memory_limit = 3092M
max_execution_time = 300

À propos de PostgreSQL config (exécutez cette requête):

SET statement_timeout TO 0;

À propos de proxy, (ou Apache mod_proxy), cela peut également être dû à la configuration du délai d'expiration du proxy

1
A STEFANI