ASIHTTPRequest, request sent twice

Question

I just started using ASIHTTPRequest for iOs and I have a little problem with it. All requests are sent twice to the server, although I get only one response from the library to the delegate methods.

Both synchronization and asynchronous requests have this problem. I use Xcode 4 with ARC, but disabled it for ASIHTTPRequest, adding -fno-objc-arc as compiler flags.

Any idea what is wrong ..?

Code:

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; [request startSynchronous]; NSError *error = [request error]; if (!error) { } 

Answer 1

It also bit me. I used the GET request to check the reuse of the voucher code on the server. When we added a speed limit to redeem codes, some customers reported exceeding the limit before they appeared. It turns out that some of the checks caused two ransoms.

Your request uses the GET method.

The default behavior when using GET is to allow persistent connections ( Keep-Alive HTTP header ).

When using a persistent connection, your GET request may be retransmitted if something on the network looks out of date (this is a technical term), and not just a request failure. This is usually desirable because GET requests often have no side effects on the server.

POST or PUT requests, on the other hand, do not use a persistent connection by default and will not retransmit your transaction, which could very well be a credit card purchase or something else with significant side effects.

If you want your ASIHTTPRequest GET to sometimes send 2 or more requests to the server (due to network problems beyond your control), you can simply set this flag:

 request.shouldAttemptPersistentConnection = NO; 

This should take care of false GET duplicates on the server.

Answer 2

Thank you for your responses. I switched to the new MKNetworkKit and never returned to ASIHttpRequest. https://github.com/MugunthKumar/MKNetworkKit

Oystine

Answer 3

It can send a HEAD request to get the size of the response, followed by a GET request to receive the content. See this section of the documentation for more details.

Answer 4

This may be due to the fact that persistent connections are used, so you see an unsuccessful request for an old connection, followed by a working request for a new connection. (GregInYEG is also true that this may be a HEAD request.)

If you collect network traces using a tool such as wirehark or charlesproxy, then you can see exactly what is happening.