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/14 06:36:03 UTC
[jira] [Comment Edited] (HTTPCLIENT-1249)
DefaultConnectionReuseStrategy -- need to honor keep alives when receiving
a 404 on a HEAD request
[ 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