9
votes

I've started using ASIHTTPRequest in my iOS project to execute REST server method calls and so far have been very successful with it. I just have one strange intermittent problem. Very occasionally I get the following response from using [ASIHTTPRequest startAsynchronous] :

HTTP/0.9 200 OK

When this occurs my server method doesn't get called. Normally every method call returns with a response starting 'HTTP/1.1'. I'm using HTTPS with a GeoTrust/RapidSSL certificate to secure the connection. Interestingly I've found that I get the same 'HTTP/0.9 200 OK' response if I try to connect to the SSL port (443) but specifying 'http' as the protocol.

Just to add more info - the problem mostly occurs after the app has been left idle for a period of time. E.g. request completes successfully, then leave app idle for a while, then on the next request the problem occurs then app continues to work fine.

Can anybody shed some light on what might be occurring?

Many thanks, Jonathan

UPDATE : I've pasted below some debug information output by ASIHTTPRequest when the problem occurred :

2012-07-12 09:35:49.376 mytestapp[3038:18f07] [CONNECTION] Closing connection #13 because it has expired
2012-07-12 09:35:49.377 mytestapp[3038:18f07] [CONNECTION] Closing connection #14 because it has expired
2012-07-12 09:35:49.378 mytestapp[3038:18f07] [CONNECTION] Closing connection #15 because it has expired
2012-07-12 09:35:49.380 mytestapp[3038:18f07] [CONNECTION] Request #39 will use connection #16
2012-07-12 09:35:49.381 mytestapp[3038:18f07] [CONNECTION] Request #40 will use connection #17
2012-07-12 09:35:49.382 mytestapp[3038:18f07] [CONNECTION] Request #41 will use connection #18
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a1e00> finished downloading data (0 bytes)
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a1e00> received response headers
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [AUTH] Request <ASIHTTPRequest: 0x88a1e00> has passed Basic authentication
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [CONNECTION] Got no keep-alive header, will keep this connection open for 60.000000 seconds
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [CONNECTION] Request #41 finished using connection #18
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Request finished: <ASIHTTPRequest: 0x88a1e00>
2012-07-12 09:35:49.531 mytestapp[3038:15803] responseHeaders={
}
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a1e00>
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a0200>
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a0200>: Cancelled
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [CONNECTION] Request #39 failed and will invalidate connection #16
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Request cancelled: <ASIHTTPRequest: 0x88a0a00>
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Request <ASIHTTPRequest: 0x88a0a00>: Cancelled
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [CONNECTION] Request #40 failed and will invalidate connection #17
3
What's your server side? Have you absolutely, 100%, categorically ruled out that the server is misbehaving by checking the actual network data stream with a packet sniffer such as Wireshark?pmdj
Any chance your ISP is using a proxy ?Lefteris
Have you tried setting "validatesSecureCertificate = NO;"endy
Thanks for the comments. The server side is a Delphi DataSnap REST server running as a Windows service (not IIS). I have other apps (Android, Win32) connecting to the same service which don't encounter this problem which are using the DataSnap client framework. I only started using ASIHTTPRequest on iOS because the iOS DataSnap framework is buggy and causes EXC_BAD_ACCESS errors. ASIHTTPRequest is working great other than this issue which only occurs maybe once or twice a day with reasonable usage. Each time it happens you just retry and it continues fine.Jonathan Wareham
I have been using Wireshark to compare the calls from my Win32/Android clients with my iOS client, and have subsequently changed the HTTP headers used in the ASIHTTPRequest to match them, but this hasn't solved the problem.Jonathan Wareham

3 Answers

2
votes

Unsure about IOS specifics in this case but HTTP 0.9 is completely abandoned. There is clear reason for this - it does not support "Host:" header. This means single IP cannot have virtual hosts at all. Such things became obsolete at end of 90-s.

Such response should never happen in real life. If it still happens, some client made request like "GET / HTTP/0.9". But these clients have disappeared ~15 years ago.

SSL is something HTTP is not much aware of. So I believe this is not related. SSL tunnel is set up and after that plain HTTP is ran.

As conclusion I would say you or someone possibly triggered obsolete method. And IOS maybe just have no idea what to do with it. Maybe IOS method is limited methods with host name included and therefore it does not trigger. Anyway you should not worry about it if client is really speaking 0.9 because it anyway does not get proper answers from most of sites. If client speaking 1.1 and you answer 0.9, then possibly request is misunderstood somehow and fallback mechanism to lowest possible HTTP version occurs. Maybe you forgot to setup host name for request or made syntax error in it?

1
votes

There are some mentions about this problem on the web, and basically it is related to persistent connections, and when something wrong with a Content-length header and a content itself that returned by some buggy servers. It could screw up the browsers and iOS framework, and they don't actually notice the headers.

Here is the one of the possible explanations.

Try to disable persistent connections, it should help. This advice came from developers of ASIHTTPRequest (quite similar situation).

[httpRequest setShouldAttemptPersistentConnection:NO]; 
0
votes

HTTP/0.9 200 OK is a non-existant message header. HTTP/0.9 is defined as the request: GET <Request-URI> HTTP/0.9 <CRLF>, the response to which is [Entity-Body], without any status lines nor header. (<urn:ietf:rfc:1945>)

There's an error in your software somewhere. I guess the request either failed, or it's not yet received.