David Robinson wrote:
My range_offset_limit and quick_abort_* setting were all default.
I tried setting range_offset_limit -1 - did not fix the problem
quick_abort_min 0 and quick_abort_max 0 - did not fix the problem
quick_abort_min -1 - did not fix the problem
The type of urls its having problems with are like these,
1270696241.147 3691 172.16.16.199 TCP_MISS/200 3069898 GET http://server437.files.youporn.com/e4/flv/426677_Splash.flv?e=1273284436&h=47ee1fbcb8d3ab05a06988683c2d94c1 - DIRECT/208.111.181.139 video/x-flv
1270696248.438 7293 172.16.16.199 TCP_MISS/200 1442091 GET http://server437.files.youporn.com/e4/flv/426677_Splash.flv?e=1273284436&h=47ee1fbcb8d3ab05a06988683c2d94c1&fs=4281434 - DIRECT/208.111.181.139 video/x-flv
The first one is the initial video player loading the flv. This request works correctly and the video starts to download.
The second URL is when I jump the video player slider ahead of the downloading video, note the fs=4281434 added to the url.
Its this fs= parameter that changes the behavior of the download. You could wget the first url and a flv would download. Wgetting the second url keeps making wget retry even though the website sends back a 200 OK.
I have this all setup in a lab so if you want tcpdumps I can provide them.
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Wednesday, April 07, 2010 8:36 PM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re: Squid 3.1.1 and flash video scrubbing
On Wed, 7 Apr 2010 14:41:42 -0500, David Robinson
<drobinson@xxxxxxxxxxxxxxx> wrote:
I've started doing field tests of 3.1.1 and a interesting bug has showed
up. If you try to jump ahead in a partially loaded video from
youporn.com
or redtube.com the flash player freezes and doesn't continue to download
the video. With squid off, you would be able to jump to any part of the
video and have it continue playing. I've tested this on 3.1.1, 3.1.0.14
and
3.1.0.15 and they all have the same behavior. I've also tested this on
squid 2.7 and both sites work properly.
Can some other users confirm this before I submit a bug report?
Using squid 3.1.1 on Debian 5.0.1 2.6.30.10 kernel
What range_offset_limit and quick_abort_* settings are you working with?
Also, are you able to track down any info about what the requests hitting
Squid are? headers, etc
Amos
Thanks. I've now replicated the behavior here, but it's baffling me as well.
tcpdump shows the request going out to the Server and the reply coming
back to Squid.
strace shows a series of interleaved reads from the server and writes
presumably to the client (me).
But nothing comes out the other side of Squid.
FWIW, the flash player and the server are somewhat broken and playing
bad games with HTTP/1.1 Range requests.
The fast-forward request goes out without any HTTP range information
(just the fs=NNN parameter) and comes back with these broken headers:
HTTP/1.0 200 OK
Server: Apache
Accept-Ranges: bytes
Cache-Control: max-age=259200
X-Origin: oh9
Content-Type: video/x-flv
Content-Range: bytes 4281434-10004477/10004478
Content-Length: 5723057
Age: 22208
Date: Thu, 08 Apr 2010 07:16:13 GMT
Last-Modified: Tue, 06 Apr 2010 00:19:37 GMT
Expires: Sun, 11 Apr 2010 01:06:05 GMT
Connection: close
The data content then starts with at least three bytes "FLV" which are
not part of the original object and a bunch of data which is.
It claims to be cacheable but isn't. If this "range" was merged into a
previous ranges of the object, or even fetched from the a full copy of
real object by any well behaved middleware proxy it would corrupt the
media transfer.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.1
