Les noms de paramètres de formulaire doivent-ils être codés lors d'un POST?

Question

Version rapide: Les noms des paramètres de "formulaires" envoyés en utilisant le codage standard multipart/form-data doivent-ils être codés?

version plus longue: Le formulaire de téléchargement sur 1fichier.com (un service pour télécharger de gros fichiers) utilise ce qui suit pour spécifier le paramètre de fichier à télécharger:

<input type="file" name="file[]" size="50" title="Select the files to upload" /> 

Le nom du paramètre est le fichier [] (remarquez les parenthèses). Utilisation de LiveHTTPHeaders Je vois que le paramètre est envoyé comme ceci (c'est-à-dire avec des parenthèses) lors de l'envoi du formulaire dans Firefox. Cependant, pour un program j'écris en Python, j'utilise le module poster pour pouvoir télécharger des fichiers en utilisant l'encodage standard multipart/form-data. Si j'entre le nom du paramètre avec les parenthèses, il est envoyé comme ceci:

file%5B%5D 

interne, affiche encode les noms des paramètres à l'aide de cette fonction:

def encode_and_quote(data): 
    """If ``data`` is unicode, return urllib.quote_plus(data.encode("utf-8")) 
    otherwise return urllib.quote_plus(data)""" 
    if data is None: 
     return None 

    if isinstance(data, unicode): 
     data = data.encode("utf-8") 
    return urllib.quote_plus(data) 

La documentation urllib.quote_plus dit que ce uniquement "requis pour l'attribution de valeurs de formulaire HTML lors de la création d'une chaîne de requête à entrer dans une URL". Mais ici, nous faisons un POST, donc les valeurs du formulaire ne vont pas dans l'url.

Alors, ont-ils encore besoin d'être codés, ou est-ce une erreur de poster de le faire?

Answer 1

RFC 2388 couvre les soumissions multipart/données de formulaire. La section 3 spécifie que les noms de paramètres doivent être ASCII ou codés selon RFC 2047. Par conséquent, si votre requête POST est codée en tant que multipart/form-data (ce que fait poster), alors les noms de paramètres n'ont pas besoin d'être codés de cette façon. Je suggère de déposer un bogue avec l'auteur (ahem ...), il pourrait être prêt à le réparer dans une future version;)

Une solution de contournement consiste à définir votre attribut de nom MultipartParam directement, par exemple.

p.name = 'file[]' 

Answer 2

Bien que cette question ait été résolue, j'inclus plus de détails sur la façon de creuser ces RFC.

RFC 2388 section 3 indique qu'un en-tête Content-Disposition est requis. Les données non-ASCII doivent être codées en utilisant RFC 2047 même si looks like a conflict. RFC 2183 section 2 décrit le format de cet en-tête Content-disposition. Le name s'inscrit dans la règle générale parameter de cette grammaire, mais référence RFC 2045 pour cela. There in section 5.1 vous trouvez que le côté droit d'un parameter est soit un token ou un quoted-string. Aucune production ne mentionne un format codé en URL pour les noms de formulaire. Mais [ et ] sont dans tspecials, donc ils ne peuvent pas faire partie d'un token.Nous obtenons donc

Content-Disposition: form-data; name="file[]"  (correct) 
Content-Disposition: form-data; name=file[]   (invalid) 
Content-Disposition: form-data; name="file%5B%5D" (wrong name) 
Content-Disposition: form-data; name=file%5B%5D (wrong name) 

Une note plus pour les noms de fichiers non-ASCII: le current HTML 5 specification draft ne les coder nécessite du d'une manière sûre 7 bits, mais plutôt de les transférer dans le codage utilisé tout au long de la demande. A question about non-ascii field names est ce qui m'a amené à regarder cette question aujourd'hui.