HTTP POST prarameters порядок / REST URL - PullRequest
2 голосов
/ 17 апреля 2010

Допустим, я загружаю большой файл через HTTP-запрос POST.

Скажем также, что у меня есть другой параметр (кроме файла), который называет ресурс, который обновляет файл.

Ресурс не может быть не частью URL, как вы можете сделать это с помощью REST (например, foo.com/bar/123). Допустим, это связано с сочетанием технических и политических причин.

Сервер должен игнорировать файл, если имя ресурса неверно или, скажем, IP-адрес и / или зарегистрированный пользователь не авторизован для обновления ресурса. Это легко сделать, если параметр ресурса был первым в запросе POST.

Похоже, если этот POST пришел из HTML-формы, которая содержит имя ресурса первым и поле файла второе, для большинства (всех?) Браузеров этот порядок сохраняется в запросе POST. Но было бы наивно полностью полагаться на это, не так ли?

Другими словами, порядок параметров HTTP незначителен, и клиент может создавать POST в любом порядке. Разве это не правда?

Это означает, что, по крайней мере в теории, сервер может в конечном итоге сохранить весь большой файл, прежде чем он сможет отклонить запрос.

Мне кажется, что это явный случай, когда URL-адреса RESTful имеют преимущество, поскольку вам не нужно просматривать содержимое POST, чтобы выполнить определенную авторизацию / проверку ошибок по запросу.

Вы согласны? Каковы ваши мысли, опыт?

Больше комментариев, пожалуйста! На мой взгляд, каждый, кто делает большие загрузки файлов (или любые другие загрузки файлов по этому вопросу), должен был подумать об этом.

Ответы [ 3 ]

2 голосов
/ 17 апреля 2010

Вы не можете полагаться на порядок переменных POST, это точно. Особенно вы не можете полагать, что массивы форм будут в правильном порядке при отправке / отправке формы. Возможно, вы захотите проверить учетные данные и т. Д. В другом месте, прежде чем приступить к публикации фактических данных, если вы хотите сохранить пропускную способность.

1 голос
/ 18 апреля 2010

Я бы просто вставил все необходимые переменные в строку запроса.

На клиенте,

<form action="/yourhandler?user=0&resource=name" method="post">
<input type="file" name="upload" /></form>

Получает тебя

POST /yourhandler?user=0&resource=name HTTP/1.1
Content-Type: multipart/form-data; boundary=-----
...

-----
Content-Disposition: form-data; name="upload"; filename="somebigfile.txt"
Content-Type: text/plain

...

На сервере вы сможете проверить строку запроса до завершения загрузки и при необходимости закрыть ее. (Это более или менее то же самое, что и REST, но может быть проще реализовать на основе того, с чем вам приходится работать, с технической и политической точек зрения.)

Другим вариантом может быть использование файла cookie для хранения этих данных, но это, очевидно, не удается, если у пользователя отключены файлы cookie. Вы также можете использовать заголовок Authorization.

0 голосов
/ 19 апреля 2010

Вы должны предоставить дополнительную информацию о вашем случае использования. Пока что я не вижу абсолютно никакой причины, по которой вам не следует просто ПОСТАВИТЬ крупную сущность на ресурс, который вы намереваетесь создать или обновить.

PUT /documents/some-doc-name
Content-Type: text/plain

[many bytes of text data]

Почему вы думаете, что это не является возможным решением в вашем случае?

Jan

...