62 votes

Quelle est la cause de l'erreur svn 413 Request Entity Too Large ?

Il m'arrive de recevoir une erreur "413 Request Entity Too Large" lors de la mise à jour d'un dépôt svn. Une fois que je reçois cette erreur, elle continue chaque fois que j'essaie de mettre à jour la copie de travail locale. Un nouveau checkout résout le problème, mais c'est très gênant. Le projet fait plus de 30 Go et le dépôt SVN est hébergé à l'extérieur.

Cela s'est produit dans le passé sur plusieurs ordinateurs différents, y compris des machines de développement Windows, et notre serveur de construction Linux.

La plupart des informations que j'ai trouvées sur ce sujet concernent des fichiers individuels volumineux (plus de 2 Go). Ce n'est pas le cas ici, car les plus gros fichiers sont d'environ 50-60 Mo.

Est-ce que quelqu'un d'autre a déjà rencontré ce problème et/ou connaît la cause/solution à ce problème ?

60voto

Ivan Zhakov Points 2778

Essayez d'ajouter les directives de configuration suivantes à votre fichier de configuration Apache :

LimitXMLRequestBody 8000000
LimitRequestBody 0

0 votes

Oh, merci beaucoup. J'ai eu exactement le même problème. Votre réponse l'a résolu proprement.

0 votes

Cela a fonctionné à merveille, mais savez-vous quelle est la logique derrière cela ?

0 votes

@RobForrest Par défaut, le serveur Apache limite la taille du corps de la demande pour empêcher les attaques DoS. Subversion rapporte le statut du travail au serveur en utilisant le corps de requête XML et ensuite le serveur envoie des mises à jour à cette copie de travail. La limite par défaut est de 1mb, ce qui est bien pour la plupart des configurations mais parfois pour les grandes copies de travail ce n'est pas assez.

44voto

mdh Points 141

Je n'ai pas accès à mon serveur repo (géré par le service informatique, et c'est le week-end). J'ai donc découvert que je pouvais contourner ce problème en faisant une mise à jour svn sur les sous-répertoires jusqu'à ce que l'un d'eux ne fonctionne plus. Ensuite, je suis descendu dans ce répertoire jusqu'à ce que je ne reçoive plus l'erreur 413. Ensuite, je pouvais faire une mise à jour à des niveaux plus élevés. Cela ne fonctionne peut-être pas pour tout le monde, mais cela pourrait aider à passer en cas d'urgence.

6 votes

C'est une bonne suggestion. Vous pouvez commencer au niveau supérieur en faisant "svn up *" - si cela échoue sur un sous-répertoire, il suffit d'y accéder et de répéter. Si vous avez un sous-répertoire avec beaucoup de dossiers, le fait de faire "svn up *" sur celui-ci peut être suffisant pour résoudre le problème.

0 votes

Arr... la raison pour laquelle j'essaie de nous faire passer à Git. Moins de cette drôle d'affaire.

0 votes

Merci, vos conseils m'ont aidé.

7voto

lrussell Points 2542

J'ai créé un petit script bash script pour parcourir les sous-répertoires, selon la réponse de mdh :

for dir in *; do
    [[ -e $dir ]] || continue
    echo "Updating $dir"
    svn up $dir
done
svn up

0 votes

Vous ne voulez pas analyser ls : mywiki.wooledge.org/ParsingLs Au lieu de cela, vous devriez envisager d'utiliser find ou bash globbing.

0 votes

Bon point, merci. Mis à jour pour utiliser bash à la place. Je consigne également le répertoire qui a échoué afin de pouvoir le gérer.

2 votes

Je ne sais pas pourquoi cette proposition a été rejetée. Si vous n'avez pas accès au serveur, c'est la seule chose que vous pouvez faire pour contourner le problème.

4voto

Matthew Hovey Points 1

J'ai eu ce problème récemment avec tout fichier de plus de 10 Mo. Il s'avère que j'avais oublié que j'utilisais un proxy pour le serveur svn/apache avec nginx. Changer client_max_body_size en nginx.conf a réglé le problème. J'ai laissé LimitXMLRequestBody y LimitRequestBody sur le serveur Apache à leurs valeurs par défaut.

1voto

tnorth Points 1

Par ailleurs, si vous utilisez mod_security, pensez à vérifier le paramètre SecRequestBodyLimit. Le mien était trop bas et causait le problème.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X