Ziel C - HTTP/0.9 Antwort von GET mit ASIHTTPRequest

Question

Ich habe begonnen, mit ASIHTTPRequest in meinem iOS-Projekt REST-Server-Methodenaufrufe auszuführen und waren bisher sehr erfolgreich damit. Ich habe nur ein seltsames intermittierendes Problem. In sehr seltenen Fällen erhalte ich die folgende Antwort von mit [ASIHTTPRequest startAsynchronous]:

HTTP/0.9 200 OK

Wenn diese Methode meines Servers kommt nicht aufgerufen. Normalerweise kommt jeder Methodenaufruf mit einer Antwort zurück, die 'HTTP/1.1' startet. Ich verwende HTTPS mit einem GeoTrust/RapidSSL-Zertifikat, um die Verbindung zu sichern. Interessanterweise habe ich festgestellt, dass ich dieselbe 'HTTP/0.9 200 OK' Antwort bekomme, wenn ich versuche, eine Verbindung zum SSL-Port (443) herzustellen, aber 'http' als Protokoll anzugeben.

Nur um weitere Informationen hinzuzufügen - das Problem tritt meistens auf, nachdem die App für eine gewisse Zeit im Leerlauf war. Z.B. Die Anfrage wird erfolgreich abgeschlossen. Lassen Sie die App für einige Zeit im Leerlauf, dann tritt das Problem bei der nächsten Anfrage auf und die App funktioniert weiterhin einwandfrei.

Kann jemand etwas Licht auf das werfen, was möglicherweise geschieht?

Vielen Dank, Jonathan

UPDATE: Ich habe unten einige Debug-Informationen Ausgabe von ASIHTTPRequest eingefügt, wenn das Problem aufgetreten ist:

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 

Answer 1

Ungewiss über IOS Besonderheiten in diesem Fall aber HTTP 0.9 ist vollständig verlassen. Es gibt einen klaren Grund dafür - es unterstützt keinen "Host:" - Header. Dies bedeutet, dass einzelne IP-Adressen keine virtuellen Hosts haben können. Solche Dinge wurden Ende der 90er Jahre obsolet.

Eine solche Reaktion sollte niemals im wirklichen Leben passieren. Wenn es immer noch passiert, hat ein Client eine Anfrage wie "GET/HTTP/0.9" gestellt. Aber diese Kunden sind vor 15 Jahren verschwunden.

SSL ist etwas, das HTTP nicht sehr bewusst ist. Also ich glaube das ist nicht verwandt. SSL-Tunnel wird eingerichtet und danach wird einfaches HTTP ausgeführt.

Als Schlussfolgerung würde ich sagen, Sie oder jemand möglicherweise veraltete Methode ausgelöst. Und IOS haben vielleicht einfach keine Ahnung, was damit zu tun ist. Möglicherweise ist die IOS-Methode auf Methoden mit Hostnamen beschränkt und wird daher nicht ausgelöst. Trotzdem solltest du dir keine Sorgen machen, wenn der Client wirklich 0.9 spricht, weil er von den meisten Seiten keine richtigen Antworten erhält. Wenn der Client 1.1 spricht und Sie 0.9 antworten, dann wird möglicherweise die Anfrage irgendwie missverstanden und der Fallback-Mechanismus auf die niedrigst mögliche HTTP-Version tritt auf. Vielleicht haben Sie vergessen, den Host-Namen für die Anfrage einzurichten oder einen Syntaxfehler zu machen?

Answer 2

Es gibt einige Erwähnungen zu diesem Problem im Web, und im Grunde bezieht es sich auf persistente Verbindungen und wenn etwas falsch mit einem Content-length-Header und einem Inhalt selbst, die von einigen Buggy-Servern zurückgegeben. Es könnte die Browser und das iOS-Framework beschädigen, und sie bemerken die Header nicht wirklich.

Hier ist die one of the possible explanations.

Versuchen Sie, persistente Verbindungen zu deaktivieren, es sollte helfen. Diese advice kam von Entwicklern von ASIHTTPRequest (ziemlich ähnliche Situation).

[httpRequest setShouldAttemptPersistentConnection:NO]; 

Answer 3

HTTP/0.9 200 OK ist eine nicht-existente Message-Header. HTTP/0.9 ist definiert als die Anfrage: GET <Request-URI> HTTP/0.9 <CRLF>, deren Antwort [Entity-Body] ist, ohne irgendwelche Statuszeilen oder Header. (< urn: ietf: rfc: 1945 >)

Es gibt einen Fehler in Ihrer Software irgendwo. Ich schätze, die Anfrage ist entweder fehlgeschlagen oder wurde noch nicht empfangen.