Re: BufferedReader.readLine() blocks unexpected
roele wrote:
I have a method where i will handle an Input/Output Stream from a
ServerSocket. The Client sends several requests and these should be
handled in one connection.
The first request is handled as expected but the seconds request is
blocked by the requestReader.readLine() method... According to JavaDoc
i cant find anything about readLine() blocking.
Has anybody a clue what could be wrong here?
--
public void handleRequest() throws IOException {
BufferedReader requestReader = new BufferedReader(new
InputStreamReader(socket.getInputStream));
OutputStream responseStream = new
BufferedOutputStream(socket.getOutputStream());
do {
Request request = new Request();
Response response = new Response();
parseRequest(requestReader, request);
processRequest(request, response);
writeResponse(responseStream, response);
}while(keepAlive && !hasError);
request.close();
response.close();
socket.close();
}
private void parseRequest(HttpRequest request) throws IOException {
String reqString = requestReader.readLine();
//.. do something with String here
//Read on
while(requestReader.ready()) {
String reqHeaders = requestReader.readLine();
//Reached end?
if(reqHeaders == null || reqHeaders.length() == 0) {
break;
}
//.. do something with String here
}
}
As mentioned by many people, BufferedReader will block until the CR or
LF is seen. From another email, it sounds like you are trying to write
an HTTP server. I suggest you read RFC2616 carefully to understand
exactly what is involved.
For example, a GET request is defined as a request line
(<METHOD><SP><URL>[<SP><VERSION>]<CRLF>) where <SP><VERSION> is optional
and if missing indicates HTTP/0.9. This is followed by zero or more
header lines, defined as <HEADERNAME>:<SP>*<HEADERVALUE><CRLF>. Finally,
the request is terminated by a blank line (<CRLF>).
This is relatively simple to parse.
However, a POST request is a different beast completely. The basic
structure is similar, starting with a request line. However, a POST
request should also have a header that indicates the Content-Length
(i.e. how many bytes to read after the blank line), or alternatively,
the Chunked Transfer-Encoding mechanism may be used (Transfer-Encoding:
chunked), which tells the server to read the size of the next chunk,
followed by a <CRLF>, then that size bytes, repeated until a chunk of
zero bytes is read.
This was just a snippet from the RFC (from the top of my head, so don't
shoot me if I got some details wrong) - the point is that it is a
COMPLICATED standard, so trying to implement it without reading the
standard is just silly.
Hope this helps.
Rogan