[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025362#comment-14025362
]
Leif Hedstrom commented on TS-2632:
-----------------------------------
[~tufang14] Can you try the following patch please?
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 858499f..812f5d2 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -4035,8 +4035,10 @@ HttpSM::parse_range_and_compare(MIMEField *field,
int64_t content_length)
ink_assert(field != NULL && t_state.range_setup == HttpTransact::RANGE_NONE
&& t_state.ranges == NULL);
- if (content_length <= 0)
+ if (content_length <= 0) {
return;
+ }
+ // ToDo: Can this really happen?
if (content_length == INT64_MAX) {
t_state.range_setup = HttpTransact::RANGE_NOT_HANDLED;
return;
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 08f4146..9ba5186 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -1848,7 +1848,9 @@ HttpTransact::OSDNSLookup(State* s)
StartAccessControl(s); // If skip_dns is enabled and no ip based
rules in cache.config and parent.config
// Access Control is called after DNS response
} else {
- if ((s->cache_info.action == CACHE_DO_NO_ACTION) &&
s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE)) {
+ if ((s->cache_info.action == CACHE_DO_NO_ACTION) &&
+ (((s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE) &&
!s->txn_conf->cache_range_write) ||
+ s->range_setup == RANGE_NOT_SATISFIABLE || s->range_setup ==
RANGE_NOT_HANDLED))) {
TRANSACT_RETURN(SM_ACTION_API_OS_DNS, HandleCacheOpenReadMiss);
} else if (s->cache_lookup_result == HttpTransact::CACHE_LOOKUP_SKIPPED)
{
TRANSACT_RETURN(SM_ACTION_API_OS_DNS, LookupSkipOpenServer);
@@ -3085,7 +3087,8 @@ HttpTransact::HandleCacheOpenReadMiss(State* s)
// We must, however, not cache the responses to these requests.
if (does_method_require_cache_copy_deletion(s->method) &&
s->api_req_cacheable == false) {
s->cache_info.action = CACHE_DO_NO_ACTION;
- } else if (s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE)) {
+ } else if ((s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE) &&
!s->txn_conf->cache_range_write) ||
+ s->range_setup == RANGE_NOT_SATISFIABLE || s->range_setup ==
RANGE_NOT_HANDLED) {
s->cache_info.action = CACHE_DO_NO_ACTION;
} else {
s->cache_info.action = CACHE_PREPARE_TO_WRITE;
{code}
This restores the code such that the new behavior (triggered on the presence of
a Range: header) only happens if the new configuration is not enabled. When
enabled, the code should be identical in behavior as 4.2.x.
Please let me know if this looks good, and that it solves the problem you are
seeing.
> Range request will always lock object in cache, even thought it's rarely
> cacheable
> ----------------------------------------------------------------------------------
>
> Key: TS-2632
> URL: https://issues.apache.org/jira/browse/TS-2632
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache, HTTP
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: range.diff
>
>
> Right now, if a client sends a Range: request, we still lock the URL in the
> cache, under the assumption that it will be written to. Since we don't
> support partial objects, in almost all cases, we'll not write the object and
> therefore release the object.
> I suggest we change this such that we never try to write lock a URL in the
> presence of a Range: header in the client request. This will allow other
> requests to go to origin faster, and better yet, it allows a request without
> a Range: header to properly lock the URL for writing. This turns out to be
> important for implementing e.g. "background filling" as a plugin.
> There is one use case where this might be useful; If the origin does not
> respond with a 206 (partial object), we can now cache the full object.
> However, this is a pretty rare case, and for someone to support this, all you
> have to do is to remove the Range: header on the request.
> I'm opening up this bug right now for discussion, if anyone have any concerns
> about this change, please let me know. It is an "incompatible" change,
> without configuration options, but that should be ok for the v5.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
