Müssen Formular-Parameternamen beim POST verschlüsselt werden?

Question

Quick-Version: Werden die Namen der Parameter von "Formularen" gesendet, die den Standard multipart/form-data Codierung müssen codiert werden?

Längere Version: Die Upload-Formular auf 1fichier.com (ein Service, große Dateien laden) verwendet die folgende Datei Parameter, um laden:

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

Der Name des Parameters Datei [] (beachten Sie die Klammern).

Verwendung von LiveHTTPHeaders Ich sehe, dass der Parameter wie folgt (d. H. Mit Klammern) gesendet wird, wenn das Formular in Firefox gesendet wird. Aber für eine program Ich schreibe in Python, verwende ich das poster Modul, um Dateien mit dem Standard multipart/form-data Codierung hochladen können. Wenn ich die Parameternamen mit den Klammern gibt, wird es wie folgt gesendet:

file%5B%5D 

Intern Plakat der Namen der Parameter kodiert diese Funktion verwenden:

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) 

Die urllib.quote_plus Dokumentation sagt, dass dies nur "erforderlich für das Zitieren von HTML-Formularwerten beim Erstellen einer Abfragezeichenfolge zum Aufrufen einer URL". Aber hier machen wir einen POST, also gehen die Formularwerte nicht in die URL.

Also, müssen sie noch codiert werden, oder ist es ein Fehler des Posters, dies zu tun?

Answer 1

RFC 2388 umfasst mehrteilige/Formulardatenübermittlungen. Abschnitt 3 spezifiziert, dass Parameternamen entweder ASCII oder gemäß RFC 2047 kodiert sein sollten.

Wenn also Ihre POST-Anfrage als multipart/form-data kodiert ist (was plakat macht), dann müssen keine Parameternamen auf diese Weise codiert werden. Ich schlage vor, einen Fehler mit dem Autor zu archivieren (ähem ...), er könnte bereit sein, es in einer zukünftigen Version zu beheben;)

Eine Problemumgehung besteht darin, das Attribut name des MultipartParam direkt festzulegen, z.

Answer 2

Obwohl im Wesentlichen diese Frage beantwortet wurde, schließe ich einige weitere Details ein, wie man durch diese RFCs graben kann.

RFC 2388 section 3 gibt an, dass ein Content-Disposition-Header erforderlich ist. Nicht-ASCII-Daten sollten unter Verwendung von RFC 2047 codiert werden, obwohl dies looks like a conflict ist. RFC 2183 section 2 beschreibt das Format dieses Content-disposition-Headers. Die name passt in die allgemeine parameter Regel dieser Grammatik, verweist dafür aber auf RFC 2045. There in section 5.1 finden Sie, dass die rechte Seite einer parameter entweder eine token oder eine quoted-string ist. Keine Produktion erwähnt irgendein URL-codiertes Format für Formnamen. Aber [ und ] sind in tspecials, so dass sie nicht Teil einer token sein können.So bekommen wir

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) 

Noch eine Anmerkung für Nicht-ASCII-Dateinamen: die current HTML 5 specification draft erfordert kodieren sie nicht in einer 7-Bit-sicheren Art und Weise, sondern sie in der gesamten Antrag verwendet Codierung übertragen. A question about non-ascii field names hat mich dazu gebracht, diese Frage heute zu sehen.