[
https://issues.apache.org/jira/browse/HTTPCORE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490754
]
Oleg Kalnichevski commented on HTTPCORE-66:
-------------------------------------------
Hi Steffen,
I had to tweak your patch a little before committing it. In particular I wanted
to keep NHttp*Connection capable running in a full duplex mode. Therefore the
NHttpClientConnection simply could not make an assumption about the current
response being received matching the current request.
I also think setting the entity to null when handling HEAD requests is
perfectly okay. I personally prefer this to extending
NHttpServerConnection.submitResponse() with a boolean flag, as I generally
dislike methods that take boolean parameters. Besides, HEAD method is the only
special case, which requires special handling of response entities. It is not
worth polluting NHttp*Connection classes with protocol logic that clearly
belongs to the service handler layer.
Please review the changes in revision 531281 and if they are okay with you I'll
close the issue.
Anyways, this is a pretty major contribution. Many thanks for sending the patch
Oleg
> Handling of HEAD requests
> -------------------------
>
> Key: HTTPCORE-66
> URL: https://issues.apache.org/jira/browse/HTTPCORE-66
> Project: HttpComponents Core
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0-alpha4
> Reporter: Steffen Pingel
> Assigned To: Oleg Kalnichevski
> Fix For: 4.0-alpha5
>
> Attachments: httpcore-nio-head-request.patch
>
>
> I noticed that there currently is no test case that sends HEAD requests in
> the NIO package. I have attached a simple test case that sends GET requests
> followed by HEAD requests and compares the received headers.
> The patch also contains modifications of httpcore-nio to make the test case
> run successfully. The tricky part on the server side is that the request
> method (which is only stored in HttpRequest) needs to be known when sending
> the response. Also HEAD responses must not contain a body but in order to
> send correct headers information about the entity such as content length and
> encoding needs to be known when processing headers.
> The patch is a first attempt to fix this and needs more refinement, e.g.
> instead of setting the entity to null in
> BufferingHttpServiceHandler.sendResponse() extending
> NHttpServerConnection.submitResponse() with a boolean flag that determines if
> a body should be sent might be a preferable option.
> On the client side similar problems exist. The client connection needs to be
> aware if a body is to be expected when receiving a response (which depends on
> the request method of the request). The patch adds a boolean field to
> DefaultNHttpClientConnection to track this, but that will fail if requests
> are pipelined. Instead NHttpClientHandler.responseReceived() could return a
> boolean value that signals if a body is expected or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
