Michael,
Since we spoke off line about this, I implemented the changes we
discussed. That is...
To adhere to the API sendResponseHeaders should be invoked with a
contentLength of -1, i.e. no content to be sent for HEAD requests.
handler implementations that are required to handle HEAD requests will
need to specifically determine this using HttpExchange.getRequestMethod
and set the required headers manually, then invoke sendResponseHeaders
with -1. An example of this is:
if (msg.getRequestMethod().equals("HEAD")) {
msg.getRequestBody().close();
msg.getResponseHeaders().add("Transfer-encoding", chunked");
msg.sendResponseHeaders(200, -1);
}
In the case that sendResponseHeaders is invoked with a content length
greater than -1 the server will now log a warning message, and no output
stream will be created.
Updated Webrev:
http://cr.openjdk.java.net/~chegar/6886723/webrev.01/webrev/
-Chris.
Chris Hegarty wrote:
Hi Michael,
The HttpExchange implementation, sun.net.httpserver.ExchangeImpl, does
not correctly handle HEAD requests. The test, described in the
'description section' of 6886723, invokes sendResponseHeaders with a 0
responseLength, i.e. chunked encoding. The "Transfer-encoding: chunked"
header should be added to the response headers but no
ChunkedOutputStream should be created. The current implementation does
send an empty chunk causing subsequent requests on the same persistent
connection to have problems.
The solution is to correctly set response headers, but create no
corresponding OutputStreams when dealing with HEAD requests.
Webrev:
http://cr.openjdk.java.net/~chegar/6886723/webrev.00/webrev/
Thanks,
-Chris
