Добавить параметр размещения контента для uploadTask с помощью URLSession и URLRequest

Я использую URLSession 'uploadTask from file'

func uploadTask(with request: URLRequest, fromFile fileURL: URL) -> URLSessionUploadTask

Почти все работает нормально, но теперь нашему серверу нужен дополнительный параметр, такой как 'uploadKey', который будет передаваться как расположение содержимого вместе с fileName.

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

Я хочу добавить его при использовании «uploadTask из файла», чтобы избежать нехватки памяти. Подскажите, пожалуйста, как это сделать.


urlsession nsurlsession nsurlrequest urlrequest content-disposition
person infiniteLoop    schedule 06.02.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Читая вопрос, я подозреваю, что вы слегка не понимаете, что делают задачи загрузки (и, к сожалению, документация Apple нуждается в серьезном улучшении в этой области, что не помогает). Эти задачи не загружают файл так, как это сделал бы веб-браузер, если бы вы выбрали файл в форме загрузки. Вместо этого они используют файл как тело запроса на загрузку. Я думаю, что они по умолчанию предоставляют разумный Content-Type на основе имени файла, хотя я не уверен, но они не отправляют данные в кодировке формы.

Итак, если я полностью понимаю вопрос, у вас есть следующие варианты:

  1. Продолжайте использовать многостраничное кодирование. При желании можно записать составное тело в файл, а не хранить его в памяти, и использовать задачу загрузки, чтобы предоставить тело из этого файла, а не из объекта NSData.
  2. Загрузите файл, который вы пытаетесь отправить, без кодирования, как целое тело загрузки, и укажите любые дополнительные параметры, которые вам нужно предоставить в форме параметров GET в самом URL-адресе.
  3. Используйте другую кодировку, например, JSON или буферы протокола.

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

person dgatwood    schedule 07.02.2019