You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jon Christiansen (JIRA)" <ji...@apache.org> on 2012/10/12 22:25:03 UTC
[jira] [Created] (HTTPCLIENT-1249) DefaultConnectionReuseStrategy
-- need to honor keep alives when receiving a 404 on a HEAD request
Jon Christiansen created HTTPCLIENT-1249:
--------------------------------------------
Summary: 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
[jira] [Commented] (HTTPCLIENT-1249) DefaultConnectionReuseStrategy
-- need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Jon Christiansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475769#comment-13475769 ]
Jon Christiansen commented on HTTPCLIENT-1249:
----------------------------------------------
There are two sides of the coin, first is the "spec", and then there is reality.
>From the spec perspective, I believe the section you describe makes perfect sense for the results of a request for an entity that does exists, but the 404 response is for the exact opposite, it is a response when the entity you requested does not exist on the server. It makes absolutely no sense to return a Content-Length response on a 404 response on a head request, because there is NO metainformation available on the entity that was requested, since it was not able to be found.
>From the reality perspective, it appears the most prevalent HTTP server in the world, Apache HTTP Server -- the project that was responsible for the formation of the Apache foundation which this project is a descendent of, does not send the Content-Length back for 404 responses to HEAD requests. Since in actuality, we should want this client to function most appropriately/compatible in the wild when dealing with the most common webservers, it is my recommendation that this code be altered to properly handle this case.
Example:
$ curl -v -X HEAD http://hc.apache.org/httpcomponents-client-ga/Oleg
* About to connect() to hc.apache.org port 80 (#0)
* Trying 140.211.11.131...
* connected
* Connected to hc.apache.org (140.211.11.131) port 80 (#0)
> HEAD /httpcomponents-client-ga/Oleg HTTP/1.1
> User-Agent: curl/7.27.0
> Host: hc.apache.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 14 Oct 2012 04:30:16 GMT
< Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g
< Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection #0
This is the behavior that this client should be able to support, and allow keep-alives to continue to be used for the HTTP connection that received this response. There is no reason, and is wasteful to force the connection to not be able to be re-used upon receiving a response like the above.
-JC
> 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
[jira] [Comment Edited] (HTTPCLIENT-1249)
DefaultConnectionReuseStrategy -- need to honor keep alives when receiving
a 404 on a HEAD request
Posted by "Jon Christiansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475769#comment-13475769 ]
Jon Christiansen edited comment on HTTPCLIENT-1249 at 10/14/12 4:36 AM:
------------------------------------------------------------------------
There are two sides of the coin, first is the spec, and then there is reality.
>From the spec perspective, I believe the section you describe makes perfect sense for the results of a request for an entity that does exists, but the 404 response is for the exact opposite, it is a response when the entity you requested does not exist on the server. It makes absolutely no sense to return a Content-Length response on a 404 response on a head request, because there is NO metainformation available on the entity that was requested, since it was not able to be found.
>From the reality perspective, it appears the most prevalent HTTP server in the world, Apache HTTP Server -- the project that was responsible for the formation of the Apache foundation which this project is a descendent of, does not send the Content-Length back for 404 responses to HEAD requests. Since in actuality, we should want this client to function most appropriately/compatible in the wild when dealing with the most common webservers, it is my recommendation that this code be altered to properly handle this case.
Example:
$ curl -v -X HEAD http://hc.apache.org/httpcomponents-client-ga/Oleg
* About to connect() to hc.apache.org port 80 (#0)
* Trying 140.211.11.131...
* connected
* Connected to hc.apache.org (140.211.11.131) port 80 (#0)
> HEAD /httpcomponents-client-ga/Oleg HTTP/1.1
> User-Agent: curl/7.27.0
> Host: hc.apache.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 14 Oct 2012 04:30:16 GMT
< Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g
< Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection #0
This is the behavior that this client should be able to support, and allow keep-alives to continue to be used for the HTTP connection that received this response. There is no reason, and is wasteful to force the connection to not be able to be re-used upon receiving a response like the above.
-JC
was (Author: jchristiansen):
There are two sides of the coin, first is the "spec", and then there is reality.
>From the spec perspective, I believe the section you describe makes perfect sense for the results of a request for an entity that does exists, but the 404 response is for the exact opposite, it is a response when the entity you requested does not exist on the server. It makes absolutely no sense to return a Content-Length response on a 404 response on a head request, because there is NO metainformation available on the entity that was requested, since it was not able to be found.
>From the reality perspective, it appears the most prevalent HTTP server in the world, Apache HTTP Server -- the project that was responsible for the formation of the Apache foundation which this project is a descendent of, does not send the Content-Length back for 404 responses to HEAD requests. Since in actuality, we should want this client to function most appropriately/compatible in the wild when dealing with the most common webservers, it is my recommendation that this code be altered to properly handle this case.
Example:
$ curl -v -X HEAD http://hc.apache.org/httpcomponents-client-ga/Oleg
* About to connect() to hc.apache.org port 80 (#0)
* Trying 140.211.11.131...
* connected
* Connected to hc.apache.org (140.211.11.131) port 80 (#0)
> HEAD /httpcomponents-client-ga/Oleg HTTP/1.1
> User-Agent: curl/7.27.0
> Host: hc.apache.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 14 Oct 2012 04:30:16 GMT
< Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g
< Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection #0
This is the behavior that this client should be able to support, and allow keep-alives to continue to be used for the HTTP connection that received this response. There is no reason, and is wasteful to force the connection to not be able to be re-used upon receiving a response like the above.
-JC
> 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
[jira] [Updated] (HTTPCORE-318) DefaultConnectionReuseStrategy --
need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-318:
---------------------------------------
Fix Version/s: Future
> DefaultConnectionReuseStrategy -- need to honor keep alives when receiving a 404 on a HEAD request
> --------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-318
> URL: https://issues.apache.org/jira/browse/HTTPCORE-318
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.2.2
> Reporter: Jon Christiansen
> Fix For: Future
>
>
> 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
[jira] [Commented] (HTTPCLIENT-1249) DefaultConnectionReuseStrategy
-- need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475402#comment-13475402 ]
Oleg Kalnichevski commented on HTTPCLIENT-1249:
-----------------------------------------------
Jon
Based on my interpretation of the HTTP spec (RFC 2616) the servers are expected to generate a response to a HEAD request the same way if it was a GET except for not including the content body. However, either Content-Length or Transfer-Encoding headers must still be present to indicate the the resource is expected to produce a content body. Status 404 has not special requirements with regards to content bodies, so if both Content-Length or Transfer-Encoding headers are absent the client has to assume the end of the message will be indicated by closing connection (see section 4.4 Message Length). All this makes believe the current behaviour of DefaultConnectionReuseStrategy is actually correct. Please let me know if you agree.
Oleg
---
9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
---
> 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
[jira] [Comment Edited] (HTTPCLIENT-1249)
DefaultConnectionReuseStrategy -- need to honor keep alives when receiving
a 404 on a HEAD request
Posted by "Jon Christiansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475769#comment-13475769 ]
Jon Christiansen edited comment on HTTPCLIENT-1249 at 10/14/12 4:36 AM:
------------------------------------------------------------------------
There are two sides of the coin, first is the spec, and then there is reality.
>From the spec perspective, I believe the section you describe makes perfect sense for the results of a request for an entity that does exist, but the 404 response is for the exact opposite, it is a response when the entity you requested does not exist on the server. It makes absolutely no sense to return a Content-Length response on a 404 response on a head request, because there is NO metainformation available on the entity that was requested, since it was not able to be found.
>From the reality perspective, it appears the most prevalent HTTP server in the world, Apache HTTP Server -- the project that was responsible for the formation of the Apache foundation which this project is a descendent of, does not send the Content-Length back for 404 responses to HEAD requests. Since in actuality, we should want this client to function most appropriately/compatible in the wild when dealing with the most common webservers, it is my recommendation that this code be altered to properly handle this case.
Example:
$ curl -v -X HEAD http://hc.apache.org/httpcomponents-client-ga/Oleg
* About to connect() to hc.apache.org port 80 (#0)
* Trying 140.211.11.131...
* connected
* Connected to hc.apache.org (140.211.11.131) port 80 (#0)
> HEAD /httpcomponents-client-ga/Oleg HTTP/1.1
> User-Agent: curl/7.27.0
> Host: hc.apache.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 14 Oct 2012 04:30:16 GMT
< Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g
< Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection #0
This is the behavior that this client should be able to support, and allow keep-alives to continue to be used for the HTTP connection that received this response. There is no reason, and is wasteful to force the connection to not be able to be re-used upon receiving a response like the above.
-JC
was (Author: jchristiansen):
There are two sides of the coin, first is the spec, and then there is reality.
>From the spec perspective, I believe the section you describe makes perfect sense for the results of a request for an entity that does exists, but the 404 response is for the exact opposite, it is a response when the entity you requested does not exist on the server. It makes absolutely no sense to return a Content-Length response on a 404 response on a head request, because there is NO metainformation available on the entity that was requested, since it was not able to be found.
>From the reality perspective, it appears the most prevalent HTTP server in the world, Apache HTTP Server -- the project that was responsible for the formation of the Apache foundation which this project is a descendent of, does not send the Content-Length back for 404 responses to HEAD requests. Since in actuality, we should want this client to function most appropriately/compatible in the wild when dealing with the most common webservers, it is my recommendation that this code be altered to properly handle this case.
Example:
$ curl -v -X HEAD http://hc.apache.org/httpcomponents-client-ga/Oleg
* About to connect() to hc.apache.org port 80 (#0)
* Trying 140.211.11.131...
* connected
* Connected to hc.apache.org (140.211.11.131) port 80 (#0)
> HEAD /httpcomponents-client-ga/Oleg HTTP/1.1
> User-Agent: curl/7.27.0
> Host: hc.apache.org
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Sun, 14 Oct 2012 04:30:16 GMT
< Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g
< Content-Type: text/html; charset=iso-8859-1
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection #0
This is the behavior that this client should be able to support, and allow keep-alives to continue to be used for the HTTP connection that received this response. There is no reason, and is wasteful to force the connection to not be able to be re-used upon receiving a response like the above.
-JC
> 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
[jira] [Moved] (HTTPCORE-318) DefaultConnectionReuseStrategy --
need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski moved HTTPCLIENT-1249 to HTTPCORE-318:
--------------------------------------------------------
Component/s: (was: HttpClient)
HttpCore
Affects Version/s: (was: 4.2.1)
4.2.2
Workflow: jira (was: Default workflow, editable Closed status)
Issue Type: Improvement (was: Bug)
Key: HTTPCORE-318 (was: HTTPCLIENT-1249)
Project: HttpComponents HttpCore (was: HttpComponents HttpClient)
> DefaultConnectionReuseStrategy -- need to honor keep alives when receiving a 404 on a HEAD request
> --------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-318
> URL: https://issues.apache.org/jira/browse/HTTPCORE-318
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.2.2
> Reporter: Jon Christiansen
> Fix For: Future
>
>
> 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
[jira] [Commented] (HTTPCORE-318) DefaultConnectionReuseStrategy --
need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Jon Christiansen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475945#comment-13475945 ]
Jon Christiansen commented on HTTPCORE-318:
-------------------------------------------
Just curious, if you were the Apache HTTPd developer responsible for programming to correctly respond for this case, how would you implement this? If you were going to actually return a Content-Length header on the 404 response to a HEAD, what value would you use? How would you derive the value?
> DefaultConnectionReuseStrategy -- need to honor keep alives when receiving a 404 on a HEAD request
> --------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-318
> URL: https://issues.apache.org/jira/browse/HTTPCORE-318
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.2.2
> Reporter: Jon Christiansen
> Fix For: Future
>
>
> 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
[jira] [Commented] (HTTPCORE-318) DefaultConnectionReuseStrategy --
need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476083#comment-13476083 ]
Oleg Kalnichevski commented on HTTPCORE-318:
--------------------------------------------
Jon
I cannot I speak for HTTPD developers. Apparently they know a great deal more about upcoming HTTP protocol changes than I. I can only tell you how server side protocol handlers in HttpCore implement GET request processing. RFC 2616 is actually pretty clear as to how HEAD should be implemented: HEAD method is identical to HEAD except it may not contain a content body (RFC2616, section 9.4). The server must generate _identical_ meta-information in the response as if they were GET requests and strip the content body. That is precisely what HttpCore server side protocol handlers do. Message meta-information clearly includes Content-Length (RFC2616, section 7.1).
If you happen to have some spare cycles it would be an enormous service to all HTTPD users if you could approach HTTPD developers and find out why on earth the newer versions HTTPD deviate from RFC 2616 (which is _the_ official HTTP spec) with regards to HEAD method handling.
Oleg
> DefaultConnectionReuseStrategy -- need to honor keep alives when receiving a 404 on a HEAD request
> --------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-318
> URL: https://issues.apache.org/jira/browse/HTTPCORE-318
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.2.2
> Reporter: Jon Christiansen
> Fix For: Future
>
>
> 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
[jira] [Commented] (HTTPCLIENT-1249) DefaultConnectionReuseStrategy
-- need to honor keep alives when receiving a 404 on a HEAD request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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