Comment puis-je définir les en-têtes des parties multipart/form-data avec django.test.Client?

Question

Chaque pièce partie dans un document multipart/form-data peut avoir ses propres en-têtes , par ex. une section peut avoir un en-tête Content-Type: text/plain. Ces parties peuvent être téléchargées à partir d'un formulaire Web, par exemple.

En the documentation for Django's UploadedFile class, je lis

UploadedFile.content_type

L'en-tête de type de contenu téléchargé avec le fichier (par exemple text/plain ou application/pdf). Comme toutes les données fournies par l'utilisateur, vous ne devriez pas croire que le fichier téléchargé est réellement ce type. Vous devrez toujours valider que le fichier contient le contenu que l'en-tête de type de contenu prétend - "confiance mais vérifier."

Bon, je devrais valider le fichier par rapport au type de contenu revendiqué. Alors bien sûr, maintenant je dois écrire des tests qui testent si mon serveur valide réellement le type de contenu correctement. Un tel test serait de faire une demande à mon serveur avec content-type: multipart/form-data, où au moins une partie a un contenu qui est incompatible avec son type de contenu.

Comment est-ce que je peux faire ceci? The django.test.Client class has a post method qui peut envoyer des demandes avec le type multipart/form-data. Les parties multiples du corps de la requête sont passées à la méthode en tant que dictionnaire. Les clés de ce dictionnaire sont des chaînes, et les valeurs sont soit des chaînes, soit des "objets de fichiers".

Je veux comprendre:

1. comment ce dictionnaire est converti en un corps de demande multipart/form-data. Quels sont les en-têtes sur chaque partie?
2. comment définir manuellement des en-têtes arbitraires sur chaque partie. Comment, par exemple, puis-je spécifier manuellement un en-tête Content-Type: text/plain?

Answer 1

1. La suite de tests Django claims il va toujours utiliser un en-tête application/octet-stream pour les fichiers. Ce n'est pas vraiment vrai cependant, car la fonction encode_file utilisée essaye réellement de guess le mime type réel du fichier.
2. Cela conduit à une réponse à votre deuxième question: avant d'essayer de deviner le type mime, la fonction looks for un content_type attribut sur le fichier. Vous devrait être en mesure de définir ceci à celui que vous aimez et écraser ainsi le Content-Type.

Answer 2

La classe Client hérite de django.test.client.RequestFactory (src) et efficace et vous pouvez le voir dans la définition de postClient qu'il est essentiellement un appel à super, de sorte que vous pouvez vous référer à la RequestFactorypost definition. Par défaut, cela appelle à son tour _encode_data qui utilise encode_multipart, qui, comme vous l'avez remarqué, spécifie "multipart/form-data".

Ici, vous pouvez voir certains en-têtes sont spécifiés pour chaque partie (par exemple, Content-Disposition), mais je ne vois pas un moyen de spécifier un en-tête Content-Type (ou un en-tête spécifique) pour chaque partie.