[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025716#comment-14025716 ] ASF subversion and git services commented on TS-2632: - Commit dda3209afae73ecd3e5cd9d53d11f2dba528cac6 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dda3209 ] TS-2632 Fixes to check the new configs properly 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025725#comment-14025725 ] ASF subversion and git services commented on TS-2632: - Commit 88deda79dc3e8408e50af4771a894d3af2a741fa in trafficserver's branch refs/heads/5.0.x from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88deda7 ] TS-2632 Fixes to check the new configs properly 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026040#comment-14026040 ] Qiang Li commented on TS-2632: -- Leif Hedstrom it works well now:-) 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021523#comment-14021523 ] Qiang Li commented on TS-2632: -- hi Leif Hedstrom i set proxy.config.http.cache.range.write enabled and my origin not support range request, it always response he full object (200 ok), so i send a range request to my ats, i get the full object, but the my ats can not cache it. curl -v -o /dev/null -H'Range:bytes=0-100' http://v1.leaderhero.com/basketball.mp4 * About to connect() to v1.leaderhero.com port 80 (#0) * Trying 58.215.133.101... connected * Connected to v1.leaderhero.com (58.215.133.101) port 80 (#0) GET /basketball.mp4 HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 Host: v1.leaderhero.com Accept: */* Range:bytes=0-100 HTTP/1.1 200 Ok Content-Type: video/mp4 Last-Modified: Mon, 06 Jan 2014 07:42:51 GMT Content-Length: 17229714 Server: ATS/4.1.2 Powered-By-VeryCDN: MISS from my ats Cache-Control: max-age=600 Date: Mon, 09 Jun 2014 02:06:52 GMT Age: 0 Connection: keep-alive Via: http/1.1 utn-cz-1-3-s18p1 (ApacheTrafficServer/5.0.0 [cMsSf ]) 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021539#comment-14021539 ] Leif Hedstrom commented on TS-2632: --- And this worked before this change? 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021542#comment-14021542 ] Qiang Li commented on TS-2632: -- Leif Hedstrom yes, it worked before this change 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021543#comment-14021543
]
Leif Hedstrom commented on TS-2632:
---
Ok, I'll take a look first thing tomorrow. You set
{code}
CONFIG proxy.config.http.cache.range.write INT 1
{code}
right ?
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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021544#comment-14021544 ] Qiang Li commented on TS-2632: -- Leif Hedstrom yes i set CONFIG proxy.config.http.cache.range.write INT 1 in my records.config 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021547#comment-14021547 ] Leif Hedstrom commented on TS-2632: --- Argh, I think this is a botched commit :-/. I initially had the configuration, took it out, and then put it back in again. It looks to me, I think, like I missed putting it back properly. I'll work on it tomorrow. 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005175#comment-14005175 ] ASF subversion and git services commented on TS-2632: - Commit 88fc99a47ef551e08c2dea1491016e89fd013324 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88fc99a ] TS-2632 Do not lock the object in cache (by default) on Range requests 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: Bug 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14005177#comment-14005177 ] ASF subversion and git services commented on TS-2632: - Commit 2a0ef8a0e53036730ec94008bb29c9e115163956 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2a0ef8a ] Added TS-2632. 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: Bug 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956160#comment-13956160 ] Faysal Banna commented on TS-2632: -- Well. look at the scenario. Youtube Videos .. they are cache-able. most of the downloads from download.com or cnet.com, those are also cache-able, vimeo videos, Android apps .. to count its almost uncountable. and they all generate a session based signature with certain fixed ID and serial that we use with the combination along in cacheurl plugin (cache-key) to store them and thus if range request is being applied to those objects and sites this becomes urgent to cache them in background doing a full none range request. i don't know about the locking mechanism you previously been talking about all i know is that it becomes crucial to serve cache content for range requests these days. take for instance windows updates even requesting a full file they almost always send a range request range=0- where is the full size of the file. and reply comes in with 206 which ATS at current implementation doesn't cache it. thats why also its very crucial to have this plugin. i can think of tons of scenarios that this becomes efficient enough. its just needs adjusting as have more control per request or per time base in such a way that off peak hours we can do the filling or what url/uri can be worked with. also take into consideration if it can be managed as per remap_plugin that would be great. with a logging option as to what is being processed as a background-fetch. One thing i have to mention also is the ability to adjust at what rate the background filling would go. so that we won't be overusing our origin bandwidth serving 100's of background-fetch objects at max speed (windows updates for example or maybe apple ios7 ) that may choke our bandwidth and prevent us from serving other requests at ease. much regards 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: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956504#comment-13956504 ] Leif Hedstrom commented on TS-2632: --- [~wbardwel] Yeah, I agree. My initial patch had a new configuration option, which was also overridable per transaction. I got some negative feedback on adding a new configuration, so I removed it. I've attached the original patch for review. William, can you take a look at it please? 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: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956615#comment-13956615 ] William Bardwell commented on TS-2632: -- I like the change... 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: Bug 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956011#comment-13956011 ] William Bardwell commented on TS-2632: -- It is not unusual for a server to return a full object to a range request if you are doing range requests on random stuff, especially on dynamically generated or assembled content. But those things are much less likely to be cached, although certainly not impossible. Obviously serving video, audio and PDFs that would normally get Range requests from a normal client/user-agent should support Range requests. But if you have something wacky trying to do partial object loads of everything, it could mess up your caching a bit with this change. Obviously if it is configurable, and configurable per-transaction then developers/deployers can decide which behavior they want. 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: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 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)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933438#comment-13933438 ] Alan M. Carroll commented on TS-2632: - I think overall this is a good change - it seems very unlikely that any modern server will return a full object in response to a range request. I will note, however, that for someone to support this, all you have to do is to remove the Range: header on the request as you wouldn't know until after sending the request if this would happen. 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: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 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)
