Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Sun, 14 Oct 2012 12:35:03 +0000 (UTC)
From: "Oleg Kalnichevski (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <523481596.42958.1350218103141.JavaMail.jiratomcat@arcas>
In-Reply-To: <1458557887.39490.1350073503123.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1249) DefaultConnectionReuseStrategy
 -- need to honor keep alives when receiving a 404 on a HEAD request
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475829#comment-13475829 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1249:
-----------------------------------------------

Likewise, there is reality and there are interpretations of reality. 

No one is infallible including HTTPD developers. Current behaviour of Apache HTTPD 2.4.1 is (in my opinion) wrong from the RFC 2616 perspective. As you can see from your own input curl is also assuming that the response is to be terminated by closing the connection (no chunk, no close, no size. Assume close to signal end). 

However, current revision of HTTPbis [1] seems to suggest that Content-Length may be optional for a response to a HEAD

---
A server MAY send a Content-Length header field in a response to a HEAD request (Section 5.3.2 of [Part2]); a server MUST NOT send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent in the payload body of a response if the same request had used the GET method. 
--- 

This, however, makes no sense to me as it removes the only cheap means of finding out content length of a resource. Having said all that once HTTPbis becomes an official standard specification we will have no other choice but to comply.  

If you feel very strongly about this issue feel free to raise an issue with HTTPD developers and ask them about their take on the matter. For the meantime I'll change the issue to change request and target it at FUTURE (no immediate plans to implement).

Oleg 

[1] https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#header.content-length 
                
> DefaultConnectionReuseStrategy -- need to honor keep alives when receiving a 404 on a HEAD request
> --------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1249
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1249
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.2.1
>            Reporter: Jon Christiansen
>
> Code will not allow connection reuse if Content-Length header is not present.
> If the request was a HEAD request and the response is a 404, this header is not present, but HttpClient should still be able to re-use the connection.
> It should be very easy to add special case code when dealing with responses to HEAD requests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org