There is a _possibility_ that this is legitimate traffic and not a varnish issue.
"206" responses happen in requests for video content when a client (like a media player) specifically requests that a "chunk" be delivered by sending a "Range:" header; the server sends a 206 status and several extra header fields in its response to acknowledge its ability to recognize the request, ability and willingness to send just a piece of the file rather than the whole file, and to indicate that the content it is giving represents only a partial piece of the file requested. For example, a media player is playing a video that exists at a URL and the user fast-forwards to a certain point on the timeline, the player can stop the current play, requests a chunk it calculates is at that position in the timeline, and resume from that point forward. It could also theoretically use the same mechanism to populate it's internal cache. There are references here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html (search for "206 Partial Content"), here ( http://en.wikipedia.org/wiki/Http_status_codes#2xx_Success) and here: http://labs.apache.org/webarch/http/draft-fielding-http/p5-range.html#status.206 Hope this helps, -Mit On Thu, Oct 6, 2011 at 5:59 PM, Kurt Kraut <[email protected]> wrote: > Hi, > > > I've already reported this on Varnish 3.0 and I waited to test it on > Varnish 3.0.1 and the behaviour is the same. The majority of HTTP GET of > files larger than 1mb are constantly interrupted and restarted with HTTP > 206. Here is a sample collected from varnishncsa: > > 177.26.0.252 - - [06/Oct/2011:18:40:50 -0300] "GET > http://video.kurtkraut.net/static/user/16/16855/0ae200b1a77438c17b1624d3987dc782.mp4HTTP/1.1"; > 206 2 "-" "AppleCoreMedia/1.0.0.8H7 (iPhone; U; CPU OS 4_3_2 like > Mac OS X; pt_br)" > 177.26.0.252 - - [06/Oct/2011:18:40:50 -0300] "GET > http://video.kurtkraut.net/static/user/16/16855/0ae200b1a77438c17b1624d3987dc782.mp4HTTP/1.1"; > 206 2 "-" "AppleCoreMedia/1.0.0.8H7 (iPhone; U; CPU OS 4_3_2 like > Mac OS X; pt_br)" > 177.26.0.252 - - [06/Oct/2011:18:40:50 -0300] "GET > http://video.kurtkraut.net/static/user/16/16855/0ae200b1a77438c17b1624d3987dc782.mp4HTTP/1.1"; > 206 2 "-" "AppleCoreMedia/1.0.0.8H7 (iPhone; U; CPU OS 4_3_2 like > Mac OS X; pt_br)" > 177.26.0.252 - - [06/Oct/2011:18:40:50 -0300] "GET > http://video.kurtkraut.net/static/user/16/16855/0ae200b1a77438c17b1624d3987dc782.mp4HTTP/1.1"; > 206 - "-" "AppleCoreMedia/1.0.0.8H7 (iPhone; U; CPU OS 4_3_2 like > Mac OS X; pt_br)" > > And this goes on for the next 14 lines, until all data was transfered. Full > log except in http://pastebin.com/7r6gQsia > > This was an iPhone watching a MP4 video, but this also happens with curl, > wget, Firefox, anything I've tested. If I point the FQDN straight to the > backend it doesn't happen. Also, different backends (Apache, nginx were > tested) the result is the same. I have three varnish 3.0.1 servers on > different servers, on different datacenters, with different CentOS installs > and they all behave the same. > > I belive this is a bug, so my question is: > > 1) Is it a known issue? > 2) If not, what further details would be helpful to make a bug report? > 3) Does anyone suggest a workaround for this? > > > Thanks in advance, > > Kurt Kraut > > _______________________________________________ > varnish-misc mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- Will 'Mit' Rowe Stagename* *1-866-326-3098 [email protected] <[email protected]> www.stagename.com Twitter: @stagename Facebook: facebook.com/stagename
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
