Ende eines HTTP Response/Request

[Kalkulon]

Ich will überprüfen, ob ein HTTP Request oder Response schon abgeschlossen wurde. Gibt es ein Zeichen, was das Ende eines HTTP Response/Request markiert?

 

[ice-breaker]

\r\n\r\n

bei Post gilt aber meine ich erst das 2. Vorkommen

 

[Dow Jones]

Nein, ein einzelnes Zeichen gibt es leider nicht. Du musst erstmal den Header des Request/Response einlesen (endet mit einer Leerzeile, also mit "\r\n\r\n" oder mit "\n\n") und dann austüfteln wie viele Bytes noch für den Body folgen. Wie das bei HTTP/1.1 offiziell funktionieren sollte steht in RFC2616.

Kurz gefasst:
1) prüfen ob überhaupt ein Body vorgesehen ist
2) das Feld Transfer-Encoding prüfen ob chunked-encoding benutzt wird
3) das Feld Content-Length prüfen ob eine Länge in Bytes angegeben ist
4) das Feld Content-Type prüfen ob multipart/byteranges angegeben ist
5) wenn nichts davon zutrifft: Daten einlesen bis die Verbindung geschlossen wird

4.4 Message Length

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.

2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.

4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1,3 or 5 of
this section.

5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)

For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.

All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.

Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored.

When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

Zitiert aus RFC2616 - HTTP/1.1: HTTP Message - 4.4 Message Length

 

[Kalkulon]

Vielen dank!

 

[Unregestriert]

Ich greif mal das Thema auf...

Hier mal ein mini bsp.:

		ServerSocket ss = new ServerSocket(1337);
		Socket s = ss.accept();
		BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
		String line = null;
		while ((line = in.readLine()) != null)
			System.out.println(line);
		System.out.println("done");

Das Programm bleibt immer in der while schleife hängen...völlig egal was ich mache.

Auch das abbrechen wenn \n\n oder \r\n\r\n kommt funktioniert, da der Stream einfach so nicht endet.

 

[SlaterB]

wenn man sich einfache Beispiele im Netz anschaut,
Google
->
Single File HTTP Server Java code example - Click here to copy ->>>
Http Server : Web ServerTiny ApplicationJava
so haben die oftmals etwas in der Richtung von \r\n

anderenfalls eben warten, ist ja nicht so schlimm, ohne ordentliches Protokoll kann der Client keine saubere Verarbeitung verlangen,
wenn man den Socket in einem separaten Thread nach einer bestimmten Zeit beendet, dürften auch solche Schleifen irgendwann abbrechen

 

[Dow Jones]

Prinzipiell sollte deine Methode schon richtig sein. Versuch mal statt !=null ein ! line.isEmpty(), damit müsstest du auf jeden Fall einen Http-Header sauber einlesen können. Null wird von readline nur bei EOF zurückgeliefert, ansonsten blockiert der Aufruf solange bis neue Daten anliegen. Und da die allermeisten Httpserver Keep-Alive unterstützen würde deine Schleife auf einen Timeout der Verbinfung warten (das kann durchaus ein paar Minuten dauern) um dann vermutlich mit einer IOException nach dir zu werfen.

Mit dem "\n\n" bzw. "\r\n\r\n" im obigen Post waren übrigens die letzten Zeichen eines Headers gemeint, nicht die letzten Zeilen. Ein Header sähe also beispielsweise so aus:

HTTP/1.1 200 OK\r\n
Connection: Keep-Alive\r\n
\r\n

Da readline() aber ohnehin eine komplette Textzeile einliest (und dabei die Zeilenende-Kennung \n bzw. \r\n auch gleich abschneidet) müsste dein Code mit ! line.isEmpty() eigentlich klappen.