Objective C - HTTP/0.9 Antwort vom GET mit ASIHTTPRequest

Question

Ich habe ASIHTTPRequest in meinem iOS-Projekt angefangen zu verwenden, um REST-Server-Methodenaufrufe auszuführen und war bisher sehr erfolgreich damit. Ich habe nur ein seltsames intermittierendes Problem. Sehr gelegentlich erhalte ich die folgende Antwort beim Verwenden von [ASIHTTPRequest startAsynchronous]:

HTTP/0.9 200 OK

Wenn dies auftritt, wird meine Servermethode nicht aufgerufen. Normalerweise liefert jeder Methodenaufruf eine Antwort, die mit 'HTTP/1.1' beginnt. Ich verwende HTTPS mit einem GeoTrust/RapidSSL-Zertifikat, um die Verbindung zu sichern. Interessanterweise habe ich festgestellt, dass ich die gleiche 'HTTP/0.9 200 OK'-Antwort erhalte, wenn ich versuche, auf den SSL-Port (443) zuzugreifen, aber 'http' als Protokoll angebe.

Nur um mehr Informationen hinzuzufügen - das Problem tritt hauptsächlich auf, nachdem die App eine Weile untätig war. Zum Beispiel wird die Anfrage erfolgreich abgeschlossen, dann bleibt die App eine Weile untätig, dann tritt beim nächsten Aufruf das Problem auf, dann funktioniert die App weiterhin einwandfrei.

Kann mir jemand Licht darauf werfen, was möglicherweise vorgeht?

Vielen Dank, Jonathan

UPDATE: Ich habe unten einige Debug-Informationen ausgeben lassen, die von ASIHTTPRequest ausgegeben wurden, als das Problem auftrat:

2012-07-12 09:35:49.376 mytestapp[3038:18f07] [VERBINDUNG] Verbindung #13 wird geschlossen, weil sie abgelaufen ist
2012-07-12 09:35:49.377 mytestapp[3038:18f07] [VERBINDUNG] Verbindung #14 wird geschlossen, weil sie abgelaufen ist
2012-07-12 09:35:49.378 mytestapp[3038:18f07] [VERBINDUNG] Verbindung #15 wird geschlossen, weil sie abgelaufen ist
2012-07-12 09:35:49.380 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #39 wird Verbindung #16 verwenden
2012-07-12 09:35:49.381 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #40 wird Verbindung #17 verwenden
2012-07-12 09:35:49.382 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #41 wird Verbindung #18 verwenden
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Anfrage  hat Daten (0 Bytes) fertig heruntergeladen
2012-07-12 09:35:49.529 mytestapp[3038:18f07] [STATUS] Anfrage  hat Antwort-Header erhalten
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [AUTH] Anfrage  hat die Basic-Authentifizierung bestanden
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [VERBINDUNG] Kein Keep-Alive-Header erhalten, halte Verbindung 60.000000 Sekunden offen
2012-07-12 09:35:49.530 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #41 hat die Verbindung #18 fertig verwendet
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Anfrage beendet: 
2012-07-12 09:35:49.531 mytestapp[3038:15803] responseHeaders={
}
2012-07-12 09:35:49.531 mytestapp[3038:18f07] [STATUS] Anfrage abgebrochen: 
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Anfrage abgebrochen: 
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [STATUS] Anfrage : Abgebrochen
2012-07-12 09:35:49.532 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #39 fehlgeschlagen und wird Verbindung #16 ungültig machen
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Anfrage abgebrochen: 
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [STATUS] Anfrage : Abgebrochen
2012-07-12 09:35:49.533 mytestapp[3038:18f07] [VERBINDUNG] Anfrage #40 fehlgeschlagen und wird Verbindung #17 ungültig machen

Answer 1

Unsicher über die IOS-spezifika in diesem Fall, aber HTTP 0.9 ist vollständig veraltet. Es gibt einen klaren Grund dafür - es unterstützt nicht den "Host:"-Header. Das bedeutet, dass eine einzelne IP überhaupt keine virtuellen Hosts haben kann. Solche Dinge wurden Ende der 90er Jahre obsolet.

Ein solche Antwort sollte im echten Leben niemals vorkommen. Wenn es dennoch passiert, hat ein Client möglicherweise eine Anfrage wie "GET / HTTP/0.9" gestellt. Aber solche Clients sind vor ~15 Jahren verschwunden.

SSL ist etwas, von dem HTTP nicht viel weiß. Also glaube ich nicht, dass dies damit zusammenhängt. Ein SSL-Tunnel wird eingerichtet und danach wird plain HTTP ausgeführt.

Als Fazit würde ich sagen, dass du oder jemand möglicherweise eine veraltete Methode ausgelöst hast. Und IOS hat vielleicht einfach keine Ahnung, was damit anzufangen ist. Vielleicht ist die IOS-Methode auf Methoden mit eingeschlossenem Hostnamen beschränkt und löst deshalb nicht aus. Wie auch immer, du solltest dir keine Sorgen machen, wenn der Client wirklich 0.9 spricht, weil er ohnehin keine korrekten Antworten von den meisten Websites erhält. Wenn der Client 1.1 spricht und du 0.9 antwortest, dann wird die Anfrage möglicherweise auf irgendeine Weise missverstanden und es kommt zu einem Fallback-Mechanismus zur niedrigsten möglichen HTTP-Version. Vielleicht hast du vergessen, den Hostnamen für die Anfrage einzurichten oder einen Syntaxfehler darin gemacht?

Answer 2

Es gibt einige Hinweise zu diesem Problem im Web, und im Grunde hängt es mit persistenten Verbindungen zusammen, sowie mit Fehlern im Zusammenhang mit einem Content-Length-Header und dem Inhalt selbst, der von einigen fehlerhaften Servern zurückgegeben wird. Dies kann die Browser und das iOS-Framework durcheinander bringen, und sie bemerken die Header eigentlich nicht wirklich.

Hier ist eine der möglichen Erklärungen hier.

Versuchen Sie, die persistenten Verbindungen zu deaktivieren, das sollte helfen. Dieser Rat stammt von den Entwicklern von ASIHTTPRequest (einer ziemlich ähnlichen Situation).

[httpRequest setShouldAttemptPersistentConnection:NO];

Answer 3

HTTP/0.9 200 OK ist ein nicht vorhandener Nachrichtenheader. HTTP/0.9 wird als die Anfrage definiert: GET HTTP/0.9 , auf die die Antwort [Entity-Body] lautet, ohne Statuszeilen oder Header. ()

In deiner Software gibt es irgendwo einen Fehler. Ich vermute, dass die Anfrage entweder fehlgeschlagen ist oder noch nicht empfangen wurde.