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);
}];

UPDATE

Ну, все, що я повинен був зробити, щоб отримати цю роботу було змінити postPath, щоб включити кінцевий '/' - можливо, це очевидно для більшості, але я хотів би пояснити прийняту відповідь.

3
Ні, це весь мій код, за винятком clientWithBaseURL: ініціалізувати
додано Автор Ben Packard, джерело
Ні, це весь мій код, за винятком clientWithBaseURL: ініціалізувати
додано Автор Ben Packard, джерело
Чи використовуєте ви setParameterEncoding на клієнті перед публікацією та використовуючи $ POST (або подібне) на сервері?
додано Автор Wain, джерело

8 Відповіді

@ Mattt не відповідає вище.

HTTP/1.0 302 працював так, як ви очікували, що "POST/FOO" 302'в/BAR мав на увазі, що ви отримаєте "POST/BAR". Тим не менш, майже ніхто з клієнтів не реалізував його таким чином, і зазвичай змінював метод на GET. Це дещо зрозуміло, оскільки новий, перенаправлений ресурс користувачеві невідомий, і не слід POST волею до невідомого ресурсу.

HTTP/1.1 видаляє це до - 302 має повідомити користувачеві про перенаправлення. 307 роблять роботу перенаправлення, як ви очікували, підтримуючи метод.

AFNetworking налаштований для того, щоб діяти, як і всі інші неслухняні клієнти - 302 змінюють метод на GET, даючи клієнту можливість попередити користувача. Я тільки мав цю проблему з AFNetworking сам: я встановив деякі точки зупину, ступив, і спостерігав за зміною методу на моїх очах.

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

tl; dr - У HTTP/1.1 використовуйте 307 для перенаправлення та підтримки методу, а не 302.

2
додано
Просто дивуючись тут. AFNetworking, використовуючи 307, підтримуватиме правильний метод і тіло HTTP.
додано Автор Sandy Chapman, джерело

@ Mattt не відповідає вище.

HTTP/1.0 302 працював так, як ви очікували, що "POST/FOO" 302'в/BAR мав на увазі, що ви отримаєте "POST/BAR". Тим не менш, майже ніхто з клієнтів не реалізував його таким чином, і зазвичай змінював метод на GET. Це дещо зрозуміло, оскільки новий, перенаправлений ресурс користувачеві невідомий, і не слід POST волею до невідомого ресурсу.

HTTP/1.1 видаляє це до - 302 має повідомити користувачеві про перенаправлення. 307 роблять роботу перенаправлення, як ви очікували, підтримуючи метод.

AFNetworking налаштований для того, щоб діяти, як і всі інші неслухняні клієнти - 302 змінюють метод на GET, даючи клієнту можливість попередити користувача. Я тільки мав цю проблему з AFNetworking сам: я встановив деякі точки зупину, ступив, і спостерігав за зміною методу на моїх очах.

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

tl; dr - У HTTP/1.1 використовуйте 307 для перенаправлення та підтримки методу, а не 302.

2
додано
Просто дивуючись тут. AFNetworking, використовуючи 307, підтримуватиме правильний метод і тіло HTTP.
додано Автор Sandy Chapman, джерело

Ну, все, що я повинен був зробити, щоб змінити цю посаду, включаючи кінцевий '/' - можливо, це очевидно для більшості, але я хотів би пояснити прийняту відповідь.

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

Інший спосіб потенційно вирішити цю проблему - скористатися AFURLConnectionOperation -setRedirectResponseBlock і переконатися, що запит перенаправлення має правильний дієслово.

2
додано
Щоб бути зрозумілим, POST змінюється на GET в редиректі не має нічого спільного з "неправильно настроєним сервером" і всім, що пов'язано з тим, як клієнт обробляє переадресацію, яку сервер посилає . Я зіткнувся з подібною проблемою з AFNetworking навіть через сервер відправив 307 "redirect без зміни методу" відповідь.
додано Автор user686782, джерело

Ну, все, що я повинен був зробити, щоб змінити цю посаду, включаючи кінцевий '/' - можливо, це очевидно для більшості, але я хотів би пояснити прийняту відповідь.

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

Інший спосіб потенційно вирішити цю проблему - скористатися AFURLConnectionOperation -setRedirectResponseBlock і переконатися, що запит перенаправлення має правильний дієслово.

2
додано
Щоб бути зрозумілим, POST змінюється на GET в редиректі не має нічого спільного з "неправильно настроєним сервером" і всім, що пов'язано з тим, як клієнт обробляє переадресацію, яку сервер посилає . Я зіткнувся з подібною проблемою з AFNetworking навіть через сервер відправив 307 "redirect без зміни методу" відповідь.
додано Автор user686782, джерело

Я зіткнувся з подібною проблемою, коли кожен запит 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), я виключив перенаправлення і виправили проблему.

0
додано

Я зіткнувся з подібною проблемою, коли кожен запит 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), я виключив перенаправлення і виправили проблему.

0
додано

Я стикається з такою ж проблемою, я використовую 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, якщо в кінці запит має "/". Щоб вирішити цю проблему, я просто коментую ці рядки. Сподіваюся, що це допоможе.

0
додано

Я стикається з такою ж проблемою, я використовую 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, якщо в кінці запит має "/". Щоб вирішити цю проблему, я просто коментую ці рядки. Сподіваюся, що це допоможе.

0
додано
IT KPI iOS
IT KPI iOS
74 учасників

Чат обсуждения IOS. - Оффтоп, флуд, оскорбления и вбросы здесь не приняты. - За нарушение - предупреждение или mute на неделю. - За спам и рекламу - ban. Все чаты IT KPI: https://t.me/itkpi/602

ios_jobs_ua
ios_jobs_ua
27 учасників

Mobile Dev Jobs UA
Mobile Dev Jobs UA
20 учасників

Публикуем вакансии и запросы на поиск работы по направлению iOS, Android, Xamarin, RN и т.д.