You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Sudheer Vinukonda (JIRA)" <ji...@apache.org> on 2015/03/05 17:57:39 UTC

[jira] [Commented] (TS-3425) Conditional request headers not included in the origin request, when an API disables cache store

    [ https://issues.apache.org/jira/browse/TS-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349078#comment-14349078 ] 

Sudheer Vinukonda commented on TS-3425:
---------------------------------------

The below simple patch fixes this issue:

{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 6991325..1648c18 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -7649,7 +7649,8 @@ HttpTransact::handle_server_died(State* s)
 bool
 HttpTransact::is_request_likely_cacheable(State* s, HTTPHdr* request)
 {
-  if ((s->method == HTTP_WKSIDX_GET || s->api_req_cacheable == true) &&
+  if ((s->method == HTTP_WKSIDX_GET || s->api_req_cacheable) &&
+      !s->api_server_response_no_store &&
       !request->presence(MIME_PRESENCE_AUTHORIZATION) &&
       (!request->presence(MIME_PRESENCE_RANGE) || s->txn_conf->cache_range_write)) {
     return true;
{code}

> Conditional request headers not included in the origin request, when an API disables cache store
> ------------------------------------------------------------------------------------------------
>
>                 Key: TS-3425
>                 URL: https://issues.apache.org/jira/browse/TS-3425
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Sudheer Vinukonda
>
> We have a cache tier setup where cache is distributed among peers in a cluster. A given client request is typically mapped (url hashed) to one of the peers in the cluster and is cached in that particular peer. If the request is received in any other peer, it is forwarded to the peer that serves it from its cache. The cache is also disabled for that object on the peer that lands the initial request. With this setup, it's always a CACHE_MISS on the peer that lands the initial request. 
> ATS on the initial peer removes the conditional headers (e.g. IMS) when forwarding to the correct peer, since this is CACHE MISS. However, since, the cache is disabled on the initial peer, it should include the conditional headers letting the fwded-to peer send back a 304, instead of having to download the complete object. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)