You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2016/10/06 14:57:20 UTC
[jira] [Comment Edited] (HTTPCLIENT-1776) Handling of HEAD without
payload headers
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15552094#comment-15552094 ]
Oleg Kalnichevski edited comment on HTTPCLIENT-1776 at 10/6/16 2:56 PM:
------------------------------------------------------------------------
It turned out that the problem is caused by differences in HEAD message delineation as defined by RFC 2616 and RFC 7231
RFC 2616
{noformat}
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.
{noformat}
RFC 7231
{noformat}
4.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields
(Section 3.3) MAY be omitted.
{noformat}
Tomcat developers chose to omit payload header, which is perfectly fine. However HttpClient 4.x is compliant with RFC 2616 only. I do not feel comfortable making it partially compliant with RFC 7231 in some aspects and non-compliant in others.
I suggest that we leave things as is in the 4.5.x branch and fix the issue in trunk. One could still use a custom {{ConnectionReuseStrategy}} to make HttpClient 4.5 ignore payload header fields for HEAD responses if needed.
Oleg
was (Author: olegk):
It turned out that the problem is caused by differences in HEAD message delineation as defined by RFC 2616 and RFC 7231
RFC 2616
{noformat}
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.
{noformat}
RFC 7231
{noformat}
4.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields
(Section 3.3) MAY be omitted.
{noformat}
Tomcat developers chose to omit payload header, which is perfectly fine. However HttpClient 4.x is compliant with RFC 2616 only. I do not feel comfortable making it partially compliant with RFC 7231 in some aspects and non-compliant in others.
I suggest that we leave things as is in the 4.5.x branch and fix the issue in trunk. One could still use a custom {{ConnectionReuseStrategy}} to make HttpClient 4.5 ignore payload header fields for HEAD requests if needed.
Oleg
> Handling of HEAD without payload headers
> ----------------------------------------
>
> Key: HTTPCLIENT-1776
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1776
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.2
> Reporter: Reinhold Früsmer
> Fix For: 5.0 Alpha2
>
> Attachments: tomcat-squid-ntlm-not-stateful.pcapng, tomcat-squid-ntlm-stateful.pcapng, wire-context-log.txt, wirelog-4.5.3.txt
>
>
> Hi,
> I'm not sure if this is a problem with HttpClient itself or with Squid (3.3.8) proxy server, but maybe you could please advise.
> Our client application first sends a HEAD request for NTLM authentication with the proxy and then re-uses the execution context as described in https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html for the following POST requests.
> Using more recent versions of Tomcat on the server-side, re-using the execution context does not work anymore, the NTLM authentication negotiate-challenge is repeated forever and following POST requests with chunked transfer-encoding don't work since they are interrupted by the authentication challenge.
> I figured out the difference betweeen newer and older Tomcat versions and found the reason: previously, Tomcat automatically added a "Content-Length: 0" header to the reponse of HEAD requests. With "Bug 59310 - Content-Length of HEAD requests incorrectly computed as 0" (https://bz.apache.org/bugzilla/show_bug.cgi?id=59310), this behavior was changed and without this header, NTLM connections to the proxy don't persist anymore.
> As the content-length header is optional in a response to a HEAD request (RFC 7230), the problem must be either in HttpClient or Squid proxy.
> Thanks in advance!
> Best regards
> Reinhold
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org