Http client API (original) (raw)

Michael McMahon michael.x.mcmahon at oracle.com
Fri Aug 17 04:38:05 PDT 2012

On 17/08/12 11:59, Frank Carver wrote:

On 17 August 2012 11:30, Michael McMahon<michael.x.mcmahon at oracle.com> wrote:

2) What is the impact on the sendHeader, setBody for HEAD requests? Ah yes, HEAD needs special treatment - though not with respect to the methods above as HEAD is identical to GET except with respect to any returned response body.

So, we need to clarify that HttpResponse.getContentLength() returns the value of the content-length header in the case of HEAD responses. That worries me. I would much prefer that HttpResponse.getContentLength() always returns the actual content length, which in the case of a HEAD would presumably be zero. This has the massive benefit that any code which reads and processes a response can be completely generic and re-usable, does not need to know anything about the request, and even relatively naive code will not break if given a bodiless response from a HEAD request. Code written specifically for a response from a HEAD is highly likely to just iterate through or cherry-pick the returned headers, including content-length, transfer-encoding and any other headers which have implications for how the body should be processed. My preference would be to leave the headers alone so the original data is available if anyone wants it, but make sure any special-case accessor methods always return directly usable values.

I take your point Frank. I agree, it's probably wrong to complicate the overwhelmingly common situation with this special case.

Maybe we could just add some text to the HttpResponse.getContentLength() method.

"Note. This method will always return zero in response to a HEAD request. The response headers must be queried directly to get the Content-length from a HEAD response."

Frank.

More information about the net-dev mailing list