[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
