Как правильно обрабатывать HTTP-дайджест-аутентификацию на iPhone - PullRequest
Новая
       16

Как правильно обрабатывать HTTP-дайджест-аутентификацию на iPhone

1 голос
/ 13 мая 2010

Я пытаюсь загрузить файл на свой персональный сервер.

Я написал небольшую php-страницу, которая пока работает безупречно.

Маленькая странная вещь заключается в том, что я генерирую все тело HTTP-сообщения, которое я собираюсь отправить (скажем, это составляет ~ 4 МБ), а затем отправляю запрос на свой сервер.

Затем сервер запрашивает HTTP-запрос и подключение моего делегата: didReceiveAuthenticationChallenge: вызов отвечает на сервер с надлежащими учетными данными и данными.

Но что случилось? Данные были отправлены дважды!

Фактически я заметил, что когда я добавил индикатор выполнения .. приложения отправляют данные (4 МБ), сервер запрашивает аутентификацию, приложения повторно отправляют данные с аутентификацией (еще 4 МБ). Итак, в конце я отправил 8mb. Это неправильно.

Я начал искать и искать решение, но не могу понять, как это исправить.

Вариантов сценария два (мое предположение):

  • Совместное использование области для всего сеанса (минимальный HTTP-запрос, затем запрос, затем данные)
  • Использовать синхронизированный способ для выполнения HTTP-соединения (вещи, которые я не хочу делать, так как мне кажется уродливым способ обработки такого рода вещей)

Спасибо

Ответы [ 2 ]

3 голосов
/ 13 мая 2010

Вы столкнулись с недостатком протокола http: вам необходимо отправить все данные, прежде чем получить ответ с запросом аутентификации (когда вы отправляете запрос без учетных данных). Вы можете попробовать выполнить небольшую обратную передачу в качестве первого запроса в том же сеансе (как вы упомянули), например, запрос HEAD, тогда в будущих запросах будет использоваться тот же одноразовый номер.

2 голосов
/ 07 марта 2011

Слишком поздно, чтобы ответить на первоначальный запрос, но со временем, если кто-то еще прочитает это.

TL; DR: В разделе 8.2.3 RFC 2616 описан статус 100 Continue, который является всем, что вам нужно (было нужно) в такой ситуации. Также взгляните на разделы 10.1.1 и 14.20.

Клиент отправляет запрос с заголовком «Expect: 100-continue», приостанавливая запрос перед отправкой тела. Сервер использует уже полученные заголовки, чтобы принять решение, может ли этот запрос быть принят или нет (если объект - тело - получаемый объект не слишком велик, если учетные данные пользователя верны ...). Если запрос является приемлемым для сервера, он отвечает кодом состояния «100 Продолжить», клиент отправляет тело, а сервер отвечает с окончательным кодом состояния для этого запроса. Наоборот, если запрос неприемлем, сервер отвечает кодом состояния 4xx («413 Request Entity Too Large», если предоставленный размер тела слишком велик, или «401 Unauthorized» + WWW-Authenticate). : header) а клиент не отправляет тело. Получив ответ с кодом состояния 401 и соответствующей информацией WWW-Authenticate:, клиент может снова выполнить запрос и предоставить свои учетные данные.

...