AFNetworking POST отправляется как GET

Извините, если это нормально, но я пытаюсь отправить запрос с iOS с помощью AFNetworking. Используя Чарльза для мониторинга запроса, я вижу, что GET отправляется:

GET /api/updateTeamAlert/ HTTP/1.1
Host: www.******r.co
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en;q=1, fr;q=0.9, de;q=0.8, ja;q=0.7, nl;q=0.6, it;q=0.5
Connection: keep-alive
User-Agent: ****** Alerts/1.0 (iPhone Simulator; iOS 6.1; Scale/2.00)

Это нормально? Я пытаюсь выяснить, почему мои параметры POST на сервере пусты - может ли это быть причиной?

Я создаю свой запрос следующим образом:

NSDictionary *params = @{@"device_id":@"test-device", @"innings":@6, @"team":@"WashingtonNationals"};

[_client postPath:@"updateTeamAlert"
       parameters:params
          success:^(AFHTTPRequestOperation *operation, id responseObject)
{
    NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
    NSLog(@"Request Successful, response '%@'", responseStr);
}
          failure:^(AFHTTPRequestOperation *operation, NSError *error)
{
    NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);
}];

ОБНОВИТЬ

Ну, все, что я должен был сделать, чтобы заставить это работать, это изменить postPath, чтобы включить конечный символ "/" - возможно, это очевидно для большинства, но я хотел бы получить объяснение принятого ответа.

Источник

4 ответа

Решение

Ну, все, что я должен был сделать, чтобы заставить это работать, это изменить postPath, чтобы включить конечный символ "/" - возможно, это очевидно для большинства, но я хотел бы получить объяснение принятого ответа.

Приложения PHP часто имеют неправильно сконфигурированные серверы, которые теряют информацию (например, метод HTTP) при выполнении перенаправления. В вашем случае добавление / определяется каноническим путем для вашего конкретного веб-сервиса, но при перенаправлении на эту конечную точку POST был изменен в GET,

Другой способ решить эту проблему - использовать AFURLConnectionOperation -setRedirectResponseBlockи убедитесь, что запрос перенаправления имеет правильный глагол.

Источник

Ответ @ Mattt выше неверен.

HTTP / 1.0 302 работал так, как вы ожидаете, что "POST /FOO" 302'd to /BAR подразумевает, что вы получите "POST /BAR". Тем не менее, практически никто из клиентов не реализовал его таким образом и обычно изменил метод на GET. Это несколько понятно, так как новый, перенаправленный ресурс неизвестен пользователю, и не следует никуда не отправлять неизвестный ресурс.

HTTP/1.1 очищает это - 302 должны сообщить пользователю о перенаправлении. 307-е заставляют перенаправление работать, как и следовало ожидать, поддерживая метод.

AFNetworking настроен так, чтобы действовать как все другие непослушные клиенты - 302-е меняют метод на GET, давая клиенту возможность предупредить пользователя. У меня просто была эта проблема с AFNetworking: я установил несколько точек останова, прошел и наблюдал за изменением метода на моих глазах.

Я еще не проверял, что 307 работают так, как определено с AFNetworking, но независимо от того, 302 ведут себя странным образом, что HTTP/1.1 определил их для работы.

tl; dr - в HTTP/1.1 для перенаправления и поддержки метода используются 307, а не 302.

Источник

Другой случай, с которым вы столкнетесь с этой проблемой, заключается в том, что при автоматической настройке перенаправления с HTTP на HTTPS запрос POST будет перенаправлен как запрос GET, если эта настройка перенаправления работает. Простое обновление конечной точки API до HTTPS решает эту проблему.

Источник

Я столкнулся с той же проблемой, я использовал Laravel для сервера.

Если мой запрос " http://localhost/api/abc/", то метод POST, отправленный с клиента, станет методом GET на сервере. Но если мой запрос " http://localhost/api/abc" (без "/"), то сервер получит метод POST.

Я нашел основную причину из-за правила перенаправления в файле.htaccess: В моем.htaccess есть следующие строки:

# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]

Эти строки изменят метод POST на метод GET, если в конце запроса будет "/". Чтобы исправить эту проблему, я просто закомментирую эти строки. Надеюсь, это поможет.

Источник

Я столкнулся с похожей проблемой, когда каждый запрос POST интерпретировался как запрос GET. Оказывается, аналогично тому, как серверы портятся, когда вы пропускаете косую черту, тип запроса может потеряться при перенаправлении DNS www.site.com в site.com или наоборот.

В моем случае мой DNS заставляет site.com перенаправить на www.site.com, но я установил базовые URL-адреса так, чтобы они указывали на site.com, Таким образом, когда я отправил запрос в мой API на site.com/apiзапрос был перенаправлен на www.site.com/api и тип запроса был потерян, и сервер по умолчанию принял запрос GET. Поэтому я добавил www на мой базовый URL, отправил мой запрос напрямую www.site.com/api (избегая перенаправления DNS), и мои POST-запросы снова начали работать.

TL; DR: добавив www (или удаляя его, в зависимости от вашего DNS) я устранил редирект и исправил проблему.

Источник
Другие вопросы по тегам