Нужно ли кодировать имена параметров формы при выполнении POST? - PullRequest
Новая
       35

Нужно ли кодировать имена параметров формы при выполнении POST?

0 голосов
/ 03 декабря 2010

Быстрая версия: Нужно ли кодировать имена параметров "форм" с использованием стандартной кодировки multipart / form-data ?

Более длинная версия: Форма загрузки на 1fichier.com (служба для загрузки больших файлов) использует следующее для указания параметра файла для загрузки: 

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

имя параметра file [] (обратите внимание на квадратные скобки).

Использование LiveHTTPHeaders Я вижу, что параметр отправляется следующим образом (то есть с квадратными скобками) при отправке формы в Firefox.Однако для программы , которую я пишу на Python, я использую модуль poster , чтобы иметь возможность загружать файлы, используя стандартный multipart / form-data кодирование.Если я введу имя параметра в скобках, оно будет отправлено следующим образом: 

file%5B%5D

Внутренне, плакат кодирует имена параметров, используя эту функцию: 

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)

urllib.quote_plus Документация гласит, что это «требуется только для цитирования значений HTML-форм при построении строки запроса для перехода в URL».Но здесь мы выполняем POST, поэтому значения формы не указываются в URL.

Итак, их все еще нужно кодировать, или это ошибка плаката, чтобы сделать это?

Ответы [ 2 ]

1 голос
/ 05 января 2014

Хотя по сути на этот вопрос уже дан ответ, я включаю некоторые дополнительные сведения о том, как копаться в этих RFC.

RFC 2388, раздел 3 , гласит, что заголовок Content-DispositionТребуется.Данные не ASCII должны быть закодированы с использованием RFC 2047 , хотя это выглядит как конфликт . Раздел 2 RFC 2183 описывает формат этого заголовка Content-disposition.name соответствует общему правилу parameter этой грамматики, но для этого ссылается RFC 2045 . Там, в разделе 5.1 , вы обнаружите, что правая часть parameter является либо token, либо quoted-string.Ни в одном из производств не упоминается какой-либо формат в кодировке URL для имен форм.Но [ и ] находятся в tspecials, поэтому они не могут быть частью token.Таким образом, мы получаем 

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)

Еще одно примечание для имен файлов, не относящихся к ASCII: текущий черновик спецификации HTML 5 требует не кодировать их 7-битным безопасным способом, а вместо этого передавать ихв кодировке, используемой на протяжении всего запроса. Вопрос об именах полей, отличных от ascii - вот что заставило меня взглянуть на этот ваш вопрос сегодня.

1 голос
/ 03 декабря 2010

RFC 2388 относится к отправке из нескольких частей / данных формы.В разделе 3 указано, что имена параметров должны быть либо ASCII, либо закодированы в соответствии с RFC 2047 .

Так что, если ваш запрос POST закодирован как multipart / form-data (какой плакат выполняет), тогданет, имена параметров не нужно кодировать таким образом.Я предлагаю отправить сообщение об ошибке автору (хм ...), он может захотеть исправить это в будущем выпуске;)

Обходной путь - установить атрибут имени вашего MultipartParam напрямую, например, 

   p.name = 'file[]'
...