AFNetworking POST GET ретінде жіберіледі

Егер бұл қалыпты болса, мені кешіріңіз, бірақ AFN желісін пайдалану арқылы iOS-дан сұраным жіберуге тырысамын. Сұрауды бақылау үшін Чарльсті пайдалану арқылы 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» дегенді өзгертуге тура келді - мүмкін, бұл көпшілік үшін анық, бірақ мен жауапты түсініктеме алғым келеді.

3
Жоқ, бұл менің клиенттіңWithBaseURL кодын қоспағанда барлық коды: баптандыру үшін
қосылды автор Ben Packard, көзі
Жоқ, бұл менің клиенттіңWithBaseURL кодын қоспағанда барлық коды: баптандыру үшін
қосылды автор Ben Packard, көзі
Серверде $ POST (немесе ұқсас) жарияламас бұрын оны setParameterEncoding қолданып жатырсыз ба?
қосылды автор Wain, көзі

8 жауаптар

Жоғарыдағы @ mattt жауаптары дұрыс емес.

HTTP/1.0 302 Сіз «POST/FOO» 302/BAR деп логикалық түрде күткендей жұмыс істеді, сіз «POST/BAR» дегенді аласыз. Дегенмен, клиенттердің ешқайсысы осылай жасамады және әдетте GET әдісін өзгертті. Бұл жаңа, қайта бағытталатын ресурс пайдаланушыға белгісіз болғандықтан түсінікті, және POST белгісіз ресурсқа бей-жай қалмауы керек.

HTTP/1.1 бұл әрекетті өшіреді - 302-і пайдаланушыға қайта бағыттау туралы білуі керек. 307-де сіз қайта бағыттау жұмысын сіз күткендей етіп жасайсыз, әдісті сақтай аласыз.

AFNetworking - барлық басқа да жарамсыз клиенттер сияқты әрекет ету үшін орнатылады - 302-і GET-ге арналған әдісті өзгертіп, тұтынушыға ескертуге мүмкіндік береді. Мен just осы мәселені AFN желісімен жасадым: кейбір тоқтау нүктелерін орнатып, қадамдар жасадым және көз алдында көзқарасты өзгертті.

Мен 307-нің AFN желісімен анықталғандай жұмыс істегенін әлі тексерген жоқпын, бірақ 302-нің HTTP/1.1 олардың жұмыс істеуін анықтайтыны таңқаларлық әрекет.

tl; dr - HTTP/1.1 ішінде 307-ні емес, 302-ні емес, әдісті қайта бағыттау және қолдау.

2
қосылды
Тек мұнда пирсинг. 307 арқылы AFN желісі дұрыс HTTP әдісі мен корпусын қолдайды.
қосылды автор Sandy Chapman, көзі

Жоғарыдағы @ mattt жауаптары дұрыс емес.

HTTP/1.0 302 Сіз «POST/FOO» 302/BAR деп логикалық түрде күткендей жұмыс істеді, сіз «POST/BAR» дегенді аласыз. Дегенмен, клиенттердің ешқайсысы осылай жасамады және әдетте GET әдісін өзгертті. Бұл жаңа, қайта бағытталатын ресурс пайдаланушыға белгісіз болғандықтан түсінікті, және POST белгісіз ресурсқа бей-жай қалмауы керек.

HTTP/1.1 бұл әрекетті өшіреді - 302-і пайдаланушыға қайта бағыттау туралы білуі керек. 307-де сіз қайта бағыттау жұмысын сіз күткендей етіп жасайсыз, әдісті сақтай аласыз.

AFNetworking - барлық басқа да жарамсыз клиенттер сияқты әрекет ету үшін орнатылады - 302-і GET-ге арналған әдісті өзгертіп, тұтынушыға ескертуге мүмкіндік береді. Мен just осы мәселені AFN желісімен жасадым: кейбір тоқтау нүктелерін орнатып, қадамдар жасадым және көз алдында көзқарасты өзгертті.

Мен 307-нің AFN желісімен анықталғандай жұмыс істегенін әлі тексерген жоқпын, бірақ 302-нің HTTP/1.1 олардың жұмыс істеуін анықтайтыны таңқаларлық әрекет.

tl; dr - HTTP/1.1 ішінде 307-ні емес, 302-ні емес, әдісті қайта бағыттау және қолдау.

2
қосылды
Тек мұнда пирсинг. 307 арқылы AFN желісі дұрыс HTTP әдісі мен корпусын қолдайды.
қосылды автор Sandy Chapman, көзі

Міне, бұл жұмыс істеу үшін, мен бұл әрекетті орындау керек пост-пациентті «/» қосу үшін өзгертті - мүмкін, бұл көпшілік үшін анық, бірақ мен жауапты түсініктеме алғым келеді.

PHP бағдарламаларында жиі қайта бағыттау кезінде ақпаратты жоғалтатын (HTTP әдісі сияқты) қате конфигурацияланған серверлер бар. Сіздің жағдайда / сіздің жеке веб-қызметіңізге арналған канондық жолға шешілді, бірақ осы соңғы нүктеге қайта бағыттау кезінде POST GET .

Бұл мәселені ықтимал түрде шешудің тағы бір жолы - AFURLConnectionOperation -setRedirectResponseBlock пайдалану және қайта бағыттау сұрауы дұрыс етістіктің болуын қамтамасыз ету.

2
қосылды
Түсінікті болу үшін, POST дегенге GET дегенге өзгертілуінде «қате конфигурацияланбаған сервермен» ештеңе жоқ және клиент серверді қайта бағыттауды қалай өңдейтіні туралы ештеңе жоқ. . Мен AFN желісімен ұқсас мәселеге тап болдым, тіпті сервер арқылы 307 «әдісті өзгертусіз бағыттау» жауап жіберді.
қосылды автор user686782, көзі

Міне, бұл жұмыс істеу үшін, мен бұл әрекетті орындау керек пост-пациентті «/» қосу үшін өзгертті - мүмкін, бұл көпшілік үшін анық, бірақ мен жауапты түсініктеме алғым келеді.

PHP бағдарламаларында жиі қайта бағыттау кезінде ақпаратты жоғалтатын (HTTP әдісі сияқты) қате конфигурацияланған серверлер бар. Сіздің жағдайда / сіздің жеке веб-қызметіңізге арналған канондық жолға шешілді, бірақ осы соңғы нүктеге қайта бағыттау кезінде POST GET .

Бұл мәселені ықтимал түрде шешудің тағы бір жолы - AFURLConnectionOperation -setRedirectResponseBlock пайдалану және қайта бағыттау сұрауы дұрыс етістіктің болуын қамтамасыз ету.

2
қосылды
Түсінікті болу үшін, POST дегенге GET дегенге өзгертілуінде «қате конфигурацияланбаған сервермен» ештеңе жоқ және клиент серверді қайта бағыттауды қалай өңдейтіні туралы ештеңе жоқ. . Мен AFN желісімен ұқсас мәселеге тап болдым, тіпті сервер арқылы 307 «әдісті өзгертусіз бағыттау» жауап жіберді.
қосылды автор user686782, көзі

Мен кез келген POST сұрауының GET сұранысы ретінде түсіндірілуіне ұқсас мәселеге жүгірдім. Көрсетілгендей, серверлердің соқтығысып қалуына жол бермегенде, араласатын сияқты, DNS коды www.site.com сілтемесін site.com Немесе керісінше.

Менің жағдайымда www.site.com мекенжайына бағыттау үшін /code>. Осылайша, менің API-ге site.com/api мекен-жайына өтініш жіберген кезде, сұрау www.site.com/api мекен-жайына қайта бағытталды және сұрау түрі жойылды, және сервер GET сұранымын әдепкі бойынша қалдырды. Сондықтан менің базалық URL мекенжайыма www қосылды, менің сұрауымды тікелей www.site.com/api мекенжайына жіберді (DNS қайта бағыттауды болдырмау) және менің POST сұрауларым қайтадан жұмыс істей бастады .

DR; DR: www (DNS-ға байланысты оны алып тастау) арқылы қайта бағыттауды жойып, мәселені шешдім.

0
қосылды

Мен кез келген POST сұрауының GET сұранысы ретінде түсіндірілуіне ұқсас мәселеге жүгірдім. Көрсетілгендей, серверлердің соқтығысып қалуына жол бермегенде, араласатын сияқты, DNS коды www.site.com сілтемесін site.com Немесе керісінше.

Менің жағдайымда www.site.com мекенжайына бағыттау үшін /code>. Осылайша, менің API-ге site.com/api мекен-жайына өтініш жіберген кезде, сұрау www.site.com/api мекен-жайына қайта бағытталды және сұрау түрі жойылды, және сервер GET сұранымын әдепкі бойынша қалдырды. Сондықтан менің базалық URL мекенжайыма www қосылды, менің сұрауымды тікелей www.site.com/api мекенжайына жіберді (DNS қайта бағыттауды болдырмау) және менің POST сұрауларым қайтадан жұмыс істей бастады .

DR; DR: www (DNS-ға байланысты оны алып тастау) арқылы қайта бағыттауды жойып, мәселені шешдім.

0
қосылды

Мен сол проблемаға тап болдым, мен сервер үшін Laravel-ды қолданамын.

Егер менің сұрауым « http://localhost/api/abc/» болса, клиенттен POST әдісі жіберіледі серверде GET әдісі болды. Бірақ егер менің сұрауым « http://localhost/api/abc » (жоқ «/») болса, онда сервер POST әдісін алады.

Мен негізделген себебі - .htaccess файлындағы Redirect ережесі: Менің .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 файлындағы Redirect ережесі: Менің .htaccess мына жолдардан тұрады:

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

Егер бұл сұраныс «/» болса, бұл жолдар POST әдісін GET әдісіне өзгертеді. Бұл мәселені шешу үшін мен осы желілерді ғана түсіндіремін. Бұл көмекті үміт етіңіз.

0
қосылды