hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michajlo Matijkiw (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-1008) Send all variants' ETags on "variant miss"
Date Wed, 13 Oct 2010 20:15:38 GMT

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


> 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:
>  - 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

View raw message