Looks good. Only comment would be that maybe the test should (also)
exercise the more
common "HEAD" scenario where an explicit Content-length is set. Since
the test runs
a number of times, maybe the handler could alternate between chunked and
fixed length.
- Michael.
Chris Hegarty wrote:
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
