On 17/08/12 11:59, Frank Carver wrote:
On 17 August 2012 11:30, Michael McMahon<michael.x.mcma...@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."
- Michael
Frank.
