Varnish drops connections and make several HTTP 206

[Mit Rowe]

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 <listas at kurtkraut.net> 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
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>



-- 
Will 'Mit' Rowe
Stagename*
*1-866-326-3098
mit at stagename.com <josh at stagename.com>
www.stagename.com
Twitter: @stagename
Facebook: facebook.com/stagename
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20111006/073419d2/attachment-0003.html>