Request for Review 6886723: light weight http server doesn't return correct status code for HEAD requests
Chris Hegarty
chris.hegarty at oracle.com
Tue May 4 06:52:38 PDT 2010
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
More information about the net-dev
mailing list