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