Request for Review 6886723: light weight http server doesn't return correct status code for HEAD requests

[Chris Hegarty]

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
>