On 05/05/2010 11:22, Michael McMahon wrote:
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.
Thanks, I added some tests for "Content-length" also. -Chris.
- 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
