trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Harrison <>
Subject Re: trafficserver(with cacheurl plugin) return cache miss on seek request from jwplayer.
Date Fri, 31 Aug 2012 13:51:15 GMT
Quick guess - jwplayer is sending headers telling traffic server not
to serve cached content. Are there differences in what wget and
jwplayer are sending? The quickest way to find this out is probably to
run tcpdump. Something like: 'tcpdump -A -n port 80' while you run
jwplayer and wget should print out enough information to see (look for
the GET /movie.mp4.... line).

On Fri, Aug 31, 2012 at 6:32 AM, 오재경 <> wrote:
> Hi everyone.
> I've made a h264streaming plugin. The requests for movie includes query string like "start=xxxx"
added by jwplayer.
> As you know trafficserver caches all different url even if these urls indicates same
movie when cache_urls_that_look_dynamic is on.
> I use cacheurl plugin to make cache url set by file path without query string. (cacheurl.config
: http://domain/([^?]*)$1)
> With cacheurl plugin only one contents is cached even if query string is different.
> At first it looked work when i tested by wget command. Of course i made sure if only
one content is cached even different query string.
> "wget http://domain/movie.mp4?start=0"                 --> hit !
> "wget http://domain/movie.mp4?start=10"                --> hit !
> "wget http://domain/movie.mp4?start=12&key=xxx"        --> hit!
> but with jwplayer it doesn't work.
> On first request it hits but when i seek movie it doesn't hit!!"
> The requests from jwplaye are same to wget test case. But trafficserver returns cache
miss and all seek requests forwarded to origin server.
> The request by wget is "http://domain/movie.mp4?start=123" in traffic.out. Also the request
by jwplayer is "http://domain/movie.mp4?start=123" in traffic.out. same!!! but cache hit with
wget, cache miss with jwplayer.
> Anyone guess what the problem is? How can I fix it?
> Thank you.

Mark Harrison
Lead Site Reliability Engineer

View raw message