You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Qiang Li (JIRA)" <ji...@apache.org> on 2014/06/09 04:29:02 UTC
[jira] [Comment Edited] (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-tabpanel&focusedCommentId=14021523#comment-14021523 ]
Qiang Li edited comment on TS-2632 at 6/9/14 2:27 AM:
------------------------------------------------------
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
< Cache-Control: max-age=600
< Date: Mon, 09 Jun 2014 02:06:52 GMT
< Age: 0
< Connection: keep-alive
<
was (Author: tufang14):
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)