2010-10-28 17 views
3

J'ai un problème avec le téléchargement de fichiers. J'utilise FastCGI sur Apache2 (unix) pour exécuter une application compatible WSGI. Les téléchargements de fichiers, sous forme d'images, sont enregistrés dans une base de données MySQL. Cependant, les images plus grandes sont tronquées à 65535 octets. Pour autant que je sache, rien ne devrait limiter la taille des fichiers et je ne suis pas sûr de savoir lequel des éléments de ma solution causerait le problème.Est-ce que FastCGI ou Apache2 limitent les tailles de téléchargement?

Est-ce FastCGI; peut-il limiter les tailles de téléchargement de fichiers?

Est-ce Python? L'objet cgi.FieldStorage me donne un handle de fichier pour le fichier téléchargé que j'ai ensuite lu: file.read(). Est-ce que cela limite la taille des fichiers?

Est-ce MySQL? Le type de colonne pour enregistrer les données d'image est un longblob. Je pensais que cela pourrait stocker quelques Go de données. Donc, quelques MB ne devraient pas poser de problème, n'est-ce pas?

Est-ce le flups WSGIServer? Je ne trouve aucune information à ce sujet.

Mon système de fichiers peut certainement gérer des fichiers volumineux, donc ce n'est pas un problème. Des idées?

UPDATE:

Il est MySQL. J'ai obtenu python pour sortir le nombre d'octets téléchargés et il est supérieur à 65535. Donc j'ai regardé max_allowed_packet pour mysqld et le régler à 128M. Overkill, mais voulant être sûr pour le moment.

Mon seul problème maintenant est d'obtenir MySQLdb de python pour permettre le transfert de plus de 65535 octets. Est-ce que quelqu'un sait comment faire ça? Peut poster comme une question distincte.

Répondre

2

Si la couche serveur/passerelle Web tronquait les soumissions de formulaires entrants, je m'attendrais à une erreur de FieldStorage, car la troncation n'interromprait pas seulement le téléchargement du fichier mais aussi la structure multipart/form-data entière. Même si cgi.py le tolérait, il serait très peu probable d'avoir tronqué le multipart à juste le bon endroit pour laisser exactement 2 ** 16-1 octets de téléchargement de fichier.

Donc je suspecterais MySQL. LONGBLOB devrait être bien jusqu'à 2 ** 32-1, mais 65535 serait la longueur maximale d'un BLOB normal. Êtes-vous sûr les types sont ce que vous pensez? Vérifiez avec SHOW CREATE TABLE x. Quelle couche de base de données utilisez-vous pour obtenir les données?

+0

+1. Je crois que c'est aussi MySQL. Si ce n'est pas la base de données elle-même (mauvais type de colonne), alors peut-être un réglage dans le pilote. – Thilo

+0

J'utilise le module MySQLdb de python et j'appelle les procédures stockées à travers cela. Le type de colonne était à l'origine un 'BLOB', mais après avoir recherché les restrictions de taille, je l'ai mis à jour à un' LONGBLOB'. – Anthony

+0

Correct, c'était MySQL. C'était en fait des limitations sur le 'max_allowed_packet' pour le client et le serveur. – Anthony