You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Vianney Carel (JIRA)" <ji...@apache.org> on 2010/08/20 11:49:16 UTC
[jira] Created: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
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
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
[jira] Updated: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Joe Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joe Campbell updated HTTPCLIENT-981:
------------------------------------
Attachment: remove_411_status_request_compliance.patch
This patch should remove the tests and the check that the caching client was making to verify that all requests that have bodies have a content length header. A comment to the test that is marked as ignore was added to indicate why the test was removed. The test code was left in place because it might be of use to the HTTP client project in general.
This code submission is authorized by my employer with rights granted to the ASF.
> 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
>
> Attachments: remove_411_status_request_compliance.patch
>
>
> 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
[jira] Resolved: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-981.
------------------------------------------
Resolution: Fixed
Patch checked in.
Many thanks, Joe, for contributing it.
Oleg
> 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
>
> Attachments: remove_411_status_request_compliance.patch
>
>
> 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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Joe Campbell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901489#action_12901489 ]
Joe Campbell commented on HTTPCLIENT-981:
-----------------------------------------
The HTTP 1.1 spec has items that pertain to both the structure and completeness of a Request and a Response - You could Infer that a request was 'good enough' for the server to make an interpretation and supply a possible answer to the a request - but it would hard than to do something reasonable with the cache beyond saying that it should be allowed to cache any 2xx responses that make sense.
I have to admit that I am starting to lean in the direction of easing this item out of the caching code and tests rather then tying it into the HttpClient Protocol processor. I would love to get Jon's and Dave's opinion on this as well. Jon will be in the office tomorrow and I will mention it to him - Dave is here today and I will point him in the direction of this discussion.
Thanks,
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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Vianney Carel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901478#action_12901478 ]
Vianney Carel commented on HTTPCLIENT-981:
------------------------------------------
By the way, is there any good reason of validating the requests within CachingHttpClient ?
I would presume that it's for ensuring that requests are valid before using them to generate the cache's keys... but if the request is executed successfully and returning an HTTP 2xx/3xx, couldn't we assume the request is valid consequently ?
Vianney
> 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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Jonathan Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901558#action_12901558 ]
Jonathan Moore commented on HTTPCLIENT-981:
-------------------------------------------
As others have said, this check originates from the original design of the caching module as a decorator around a backend HttpClient; modelling the module's behavior as a proxy seemed like a good model for understanding the protocol requirements for it.
That said, the caching module isn't *actually* a proxy--it's just *part* of a client. As such, some of the proxy requirements can end up a little awkward. This is probably one of those cases; especially since the DefaultHttpClient already appropriately computes Content-Length, I'd be ok with removing this check from the caching module.
> 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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Joe Campbell (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-981:
-----------------------------------------
Fix Version/s: 4.1 Alpha3
> 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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901453#action_12901453 ]
Oleg Kalnichevski commented on HTTPCLIENT-981:
----------------------------------------------
There is no easy solution to this problem. Users of HttpClient are generally advised to not mess around with protocol specific headers (especially Content-Length and Transfer-Encoding) and let HttpClient generate those headers automatically. So, if a request passed to HttpClient for execution encloses an entity it HttpClient ensures a proper composition of the message head and a correct delimitation of the content body.
One could run the request through the protocol processor in order to populate the request with all mandatory headers prior to passing it to the RequestProtocolCompliance validator. This would add up to the processing overhead and increase complexity of the cache implementation.
Oleg
> 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
[jira] Commented: (HTTPCLIENT-981) CachingHttpClient returns a 411
respones when executing a POST (HttpPost) request
Posted by "David Mays (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org