hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Campbell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411 respones when executing a POST (HttpPost) request
Date Mon, 23 Aug 2010 12:56:17 GMT

    [ 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.


> 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

View raw message