< stripping the range header < How often should I say: There is no range header any more ! There was one, a year ago, may be. Now the range is within URL ! Real world example, brand new: 1396987801.026 1766 127.0.0.1 TCP_MISS/200 930166 GET http://r3---sn-a8au-nuae.googlevideo.com/videoplayback?c=web&clen=8890573&cpn=YbdH9EPrD2WaihVO&cver=as3&dur=229.296&expire=1397011183&fexp=931327%2C909708%2C943404%2C913564%2C921727%2C916624%2C931014%2C936106%2C937417%2C913434%2C936916%2C934022%2C936923%2C3300003%2C3300108%2C3300132%2C3300137%2C3300164%2C3310366%2C3310622%2C3310649&gcr=us&gir=yes&id=o-AJr0zxHxn0iVmV-Cln_bZf3PMd4um4Qt9Thok1FphZR0&ip=199.217.116.158&ipbits=0&itag=134&keepalive=yes&key=yt5&lmt=1384344824807223&ms=au&mt=1396987642&mv=u&mws=yes&range=2789376-3719167&ratebypass=yes&; !RANGE IN URL !!!!!!!!!!!!!!!!!!!!!! <-------- signature=622A2F30C82E4D26D6C9A88C2D08CBD7737DBD83.EFEABA801CDE1A0AE37F5F55161DD8994EC17788&source=youtube&sparams=clen%2Cdur%2Cgcr%2Cgir%2Cid%2Cip%2Cipbits%2Citag%2Clmt%2Csource%2Cupn%2Cexpire&sver=3&upn=b0ZrCxMNX5k - DIRECT/4.53.166.142 application/octet-stream Accept:%20*/*%0D%0AAccept-Encoding:%20gzip,deflate%0D%0AAccept-Language:%20de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4%0D%0ACache-Control:%20max-age=0%0D%0AHost:%20r3---sn-a8au-nuae.googlevideo.com%0D%0AReferer:%20http://www.youtube.com/watch?v=hSjIz8oQuko%0D%0AUser-Agent:%20Mozilla/5.0%20(Windows%20NT%206.3;%20WOW64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/33.0.1750.154%20Safari/537.36%0D%0A HTTP/1.0%20200%20OK%0D%0ALast-Modified:%20Wed,%2013%20Nov%202013%2012:13:44%20GMT%0D%0ADate:%20Tue,%2008%20Apr%202014%2020:09:57%20GMT%0D%0AExpires:%20Tue,%2008%20Apr%202014%2020:09:57%20GMT%0D%0ACache-Control:%20private,%20max-age=23086%0D%0AContent-Type:%20application/octet-stream%0D%0AAccept-Ranges:%20bytes%0D%0AContent-Length:%20929792%0D%0AAlternate-Protocol:%2080:quic%0D%0AX-Content-Type-Options:%20nosniff%0D%0AConnection:%20close%0D%0AX-UA-Compatible:%20IE=edge%0D%0A%0D And when this "....range=2789376-3719167...." is more or less random now, no chance for caching. (Unless you write very smart code to join/select the pieces, assuming, no checksum or similar nasty parameters in the URL, too.) I hope, now it is absolutely clear to you. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Do-we-have-an-algorithm-to-define-the-cachabillity-of-an-object-by-the-request-and-response-tp4665473p4665500.html Sent from the Squid - Users mailing list archive at Nabble.com.
