[
https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901513#action_12901513
]
David Mays commented on HTTPCLIENT-981:
---------------------------------------
There is a fine line that we attempt to draw in distinguishing between a
caching proxy (from which we derive our conditional compliance guidelines) and
a local cache. I think one principle we should try to follow is that if you add
CachingHttpClient into your project today, the change should not include
"getting errors you didn't get yesterday."
Ultimately, the protocol compliance of the request is the responsibility of the
HttpClient, and CachingHttpClient should trust that it will happen.
I think instead of a 411, in this case, some kind of Log.Warn or Log.Info
should be in place. Maybe CachingHttpClient should warn you that your request
*might* result in never getting a cache hit, if something about the request
makes it inherently un-cacheable in an unexpected or unusual way.
I am not initially in favor of putting in additional validations that are
already taken care of by the Protocol Processor. I am also not in favor of
doing that work twice per request. Without having looked at the code recently,
I'm not certain what sort of refactoring would have to take place to move
protocol processing further "up the chain" so that requests that went into the
cachingclient would already be guaranteed compliant. My intuition says that it
would be non-trivial.
At any rate, I am definitely not 100% solid on my position here, and would like
to get more thoughts from the community.
Dave
> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
