You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Joe Campbell (JIRA)" <ji...@apache.org> on 2010/08/23 14:56:17 UTC
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901376#action_12901376 ]
Joe Campbell commented on HTTPCLIENT-981:
-----------------------------------------
This problem I think needs a call from Oleg...
The Cache portion of this is designed and tested to be HTTP 1.1 Conditionally compliant which means that when a request is handed to it - the request has to be complete. If the request handed to the caching client has a body it has to have a content-length header according to the spec. My gut says that setting the content-length should be something that the person 'using' the client in their code should be setting and not leaving it up to the implementation to set for them, but Oleg may have a different opinion.
We could remove that validation, but I think that it should stay.
Joe
> CachingHttpClient returns a 411 respones when executing a POST (HttpPost) request
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-981
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-981
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Cache
> Affects Versions: 4.1 Alpha2
> Reporter: Vianney Carel
> Fix For: 4.1 Alpha3
>
>
> The CachingHttpClient validates requests prior executing them, by calling RequestProtocolCompliance.requestIsFatallyNonCompliant(..).
> When executing an HttpPost, this method considers the request is invalid because it does not contain (yet) a content-length header. Indeed, I observed that this header is generated at the time the DefaultHttpClient fires the request.
> NB: i'm using the Cache 4.1-alpha2 plugged over the HttpClient 4.0.1-final. I can't use the latest version for both because I need to rely on a stable version if there's any. I would be curious to know if we get the same behaviour in 4.1...
> Anyway, I would see two fixes for that issue:
> - make HttpPost set the content-length at the time the entity is set,
> - or remove the validation step on the CachingHttpClient side.
--
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org