You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Michajlo Matijkiw (JIRA)" <ji...@apache.org> on 2010/10/07 21:02:31 UTC
[jira] Created: (HTTPCLIENT-1008) Send all variants' ETags on
"variant miss"
Send all variants' ETags on "variant miss"
------------------------------------------
Key: HTTPCLIENT-1008
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: Cache
Reporter: Michajlo Matijkiw
Fix For: 4.1 Alpha3
>From section 13.6 of RFC 2616:
If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
- request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
- request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
- request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-1008:
------------------------------------------
Fix Version/s: (was: 4.1 Alpha3)
4.1.0
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1.0
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Jonathan Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921415#action_12921415 ]
Jonathan Moore commented on HTTPCLIENT-1008:
--------------------------------------------
This was probably caused because Mishu and Mohammed's patch was created against a version of trunk that predated my patch you just committed with the IOExceptions. I suspect it can be fixed just by updating the test case to add:
EasyMock.expect(mockCache.getVariantEntries(...)).andThrow(new IOException()).anyTimes();
and then putting try...catch blocks in CachingHttpClient if they are missing.
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1.0
>
> Attachments: negotiated_response.patch
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Michajlo Matijkiw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michajlo Matijkiw updated HTTPCLIENT-1008:
------------------------------------------
Attachment: negotiated_response.patch
This patch adds the functionality of negotiating responses with the server using variants. When a request is made for a resource which has a cached copy with a different vary field value, all such entries' etags are sent to the server in a conditional request allowing the server to specify an entry already in the cache if it exits. To accomplish this I needed to add HttpCache#getVariantCacheEntries(), since there was no way to retrieve variants from the cache. The method negotiateResponseFromVariants was added to CachingHttpClient to handle the necessary logic.
This patch was developed in collaboration with Mohammed Azeem Uddin and is submitted with the permission of my employer.
Thanks,
Michajlo
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1.0
>
> Attachments: negotiated_response.patch
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Michajlo Matijkiw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michajlo Matijkiw updated HTTPCLIENT-1008:
------------------------------------------
Attachment: negotiated_response_updated.patch
That was indeed the case, updated patch attached.
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1.0
>
> Attachments: negotiated_response.patch, negotiated_response_updated.patch
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921411#action_12921411 ]
Oleg Kalnichevski commented on HTTPCLIENT-1008:
-----------------------------------------------
Michajlo,
One of the test cases fails for me. Could you please have a look?
Oleg
-------------------------------------------------------------------------------
Test set: org.apache.http.impl.client.cache.TestCachingHttpClient
-------------------------------------------------------------------------------
Tests run: 56, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.235 sec <<< FAILURE!
testTreatsCacheIOExceptionsAsCacheMiss(org.apache.http.impl.client.cache.TestCachingHttpClient) Time elapsed: 0.011 sec <<< FAILURE!
java.lang.AssertionError:
Unexpected method call getVariantCacheEntries(http://foo.example.com, GET /stuff [Via: 1.1 localhost (Apache-HttpClient/4.1-alpha3-SNAPSHOT (cache))]):
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1.0
>
> Attachments: negotiated_response.patch
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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-1008) Send all variants' ETags on
"variant miss"
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1008.
-------------------------------------------
Resolution: Fixed
Fix Version/s: (was: 4.1.0)
4.1 Alpha3
Patch checked in. Many thanks, Michajlo
Oleg
> Send all variants' ETags on "variant miss"
> ------------------------------------------
>
> Key: HTTPCLIENT-1008
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1008
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Reporter: Michajlo Matijkiw
> Fix For: 4.1 Alpha3
>
> Attachments: negotiated_response.patch, negotiated_response_updated.patch
>
>
> From section 13.6 of RFC 2616:
> If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
> Presently, we simply forward the request to the request without the conditionals. This improvement would consist of adding the conditionals to the request, and properly handling the response. An example of such would be the following:
> - request resource with "Accept-Encoding: gzip", response has "Etag: etag1", "Vary: Accept-Encoding"
> - request resource with "Accept-Encoding: deflate", request is forwarded with "If-None-Match: etag1" added, response is 200, with "ETag: etag2"
> - request resource with "Accept-Encoding: gzip, deflate", request is forwarded with "If-None-Match: etag1, etag2" added, response is 304, with "ETag: etag1" indicating we should use the first response for this request
--
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