[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

["Gancho Tenev (JIRA)" <ji...@apache.org>]

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

Gancho Tenev commented on TS-4334:
----------------------------------

It seems to me that the {{cache_range_requests}} functionality can be achieved by using more generic (and feature-rich) plugins like {{header_rewrite}} and {{cachekey}}.

Here is a sample where {{httpbin.org}} is used as origin which responds to range requests adding {{Cache-Control:max-age=10}} header. 

There are 2 remap rules defined, one for {{example_no_cache.com}} which is non-caching (ATS does not cache 206 responses by default) and one for {{example.com}} which is caching exactly like the {{cache_range_requests}} plugin does.

To test run {{traffic_server}} and {{curl}} 4 times every 5 seconds - 2 times to test the non-caching remap and 2 times to test the "cache_range_requests"-style caching. 

Here are the configs:

{code}
$ cat etc/trafficserver/remap.config
map http://example.com http://httpbin.org \
    @plugin=cachekey.so @pparam=--include-headers=@Original-Range \
    @plugin=header_rewrite.so @pparam=cache_range_local.config

map http://example_no_cache.com http://httpbin.org \
    @plugin=cachekey.so


$ cat etc/trafficserver/cache_range_global.config
cond %{READ_REQUEST_HDR_HOOK}
cond %{CLIENT-URL:HOST} example.com
set-header @Original-Range %{HEADER:Range}
rm-header Range


$ cat etc/trafficserver/cache_range_local.config
cond %{SEND_REQUEST_HDR_HOOK}
set-header Range %{HEADER:@Original-Range}

cond %{READ_RESPONSE_HDR_HOOK}
cond %{STATUS} =206
set-status 200
set-header Cache-Control "max-age=10"

cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =200
set-status 206


$ cat etc/trafficserver/plugin.config
header_rewrite.so cache_range_global.config
xdebug.so
{code}

And here is a sample test:

{code}
$ sudo ./bin/traffic_server -T 'header_rewrite|cachekey' --clear_cache
. . .

$ for domain in example_no_cache.com example_no_cache.com example.com example.com; do curl -x 127.0.0.1:80 -v "http://${domain}/range/1024" -H "X-Debug: X-Cache,X-Cache-Key" -r0-16 -s 2>&1|grep -e "HTTP" -e "Cache"; echo "-------"; sleep 5; done
> GET http://example_no_cache.com/range/1024 HTTP/1.1
> X-Debug: X-Cache,X-Cache-Key
< HTTP/1.1 206 PARTIAL CONTENT
< X-Cache-Key: /example_no_cache.com/80/range/1024
< X-Cache: miss
-------
> GET http://example_no_cache.com/range/1024 HTTP/1.1
> X-Debug: X-Cache,X-Cache-Key
< HTTP/1.1 206 PARTIAL CONTENT
< X-Cache-Key: /example_no_cache.com/80/range/1024
< X-Cache: miss
-------
> GET http://example.com/range/1024 HTTP/1.1
> X-Debug: X-Cache,X-Cache-Key
< HTTP/1.1 206 Partial Content
< Cache-Control: max-age=10
< X-Cache-Key: /example.com/80/@Original-Range:bytes=0-16/range/1024
< X-Cache: miss
-------
> GET http://example.com/range/1024 HTTP/1.1
> X-Debug: X-Cache,X-Cache-Key
< HTTP/1.1 206 Partial Content
< Cache-Control: max-age=10
< X-Cache-Key: /example.com/80/@Original-Range:bytes=0-16/range/1024
< X-Cache: hit-fresh
-------
{code}

Please let me know if it works for you!
Cheers,
--Gancho

> The cache_range_requests plugin always attempts to modify the cache key.
> ------------------------------------------------------------------------
>
>                 Key: TS-4334
>                 URL: https://issues.apache.org/jira/browse/TS-4334
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: Plugins
>            Reporter: Nolan Astrein
>            Assignee: Gancho Tenev
>             Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the cache_range_requests plugin should modify the cache key.  The cache key may be modified by a previous plugin in a plugin chain and there is no way to configure cache_range_requests not to do any further modifications to the cache key.  Having multiple plugins responsible for cache key modifications can cause unexpected behavior, especially when a plugin chain ordering is changed.



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