Mailing List Archive

Handling HTML5 Video for iOS and Safari clients
Branch: varnish-5.1.2
Config: mostly default

Dear List,

there are a lot of stuff in the results of common search engines concerning
streaming mp4 files via varnish. But my mental picture is still unsharp. Therefore
following questions; It seems that Safari-Browser has still a problem with such
assets. I had tried two approaches:

1st: Just "pass" it to the backend:

vcl_recv : if ( req.url ~ "\.(mp4|webm)$" ) { return(pipe); }

or

2nd: Deliver it directly

vcl_recv : if ( req.url ~ "\.(mp4|webm)$" ) { unset req.http.cookie; }
vcl_backend_response : if ( bereq.url ~ "\.(mp4|webm)$" ) { set beresp.do_stream = true; }


Both don't help to get the Safari browser to display the video content as done by the Firefox browser for example.


So, the questions:

Which one should be the preferential approach - in general to deliver mp4 files?

Does someone has the same issues with the Safari-Browser? What could help here?

In the mean time, any other suggestions would be greatly appreciated.

Thanks,
Leon



_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
Don't pipe. ever. Unless your are using websockets.

do_stream is set by default, you can remove it.

Are we talking aboud VoD or Live? if the latter, remember to set grace to
0, other you'll have outdated manifest problems.

What isn't working on Safari? Does the problem goes away if you connect
straight to the origin? (ie. no varnish) What do the developer tools tell
you? Have you looked at varnishlog?

--
Guillaume Quintard

On Fri, Jul 21, 2017 at 12:27 AM, Leon <info+varnish@shee.org> wrote:

> Branch: varnish-5.1.2
> Config: mostly default
>
> Dear List,
>
> there are a lot of stuff in the results of common search engines concerning
> streaming mp4 files via varnish. But my mental picture is still unsharp.
> Therefore
> following questions; It seems that Safari-Browser has still a problem with
> such
> assets. I had tried two approaches:
>
> 1st: Just "pass" it to the backend:
>
> vcl_recv : if ( req.url ~ "\.(mp4|webm)$" ) { return(pipe); }
>
> or
>
> 2nd: Deliver it directly
>
> vcl_recv : if ( req.url ~ "\.(mp4|webm)$" ) { unset
> req.http.cookie; }
> vcl_backend_response : if ( bereq.url ~ "\.(mp4|webm)$" ) { set
> beresp.do_stream = true; }
>
>
> Both don't help to get the Safari browser to display the video content as
> done by the Firefox browser for example.
>
>
> So, the questions:
>
> Which one should be the preferential approach - in general to deliver mp4
> files?
>
> Does someone has the same issues with the Safari-Browser? What could help
> here?
>
> In the mean time, any other suggestions would be greatly appreciated.
>
> Thanks,
> Leon
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
Hi, a bit latency caused by vacation.


Am 21.07.2017 um 09:53 schrieb Guillaume Quintard <guillaume@varnish-software.com>:
>
> Don't pipe. ever. Unless your are using websockets.


Okay, I tried just to delete "req.http.cookie" or return(pass) both do not help here.




> do_stream is set by default, you can remove it.

Okay, thanks to clarify it.



> Are we talking aboud VoD or Live? if the latter, remember to set grace to 0, other you'll have outdated manifest problems.

VoD - plain mp4 files.


> What isn't working on Safari? Does the problem goes away if you connect straight to the origin? (ie. no varnish)


Test scenario: just GET the mp4 file and play it in the browser (HTML5).



Connecting straight to the backend (via SSH tunnel):

File size 7081786 test.mp4


$ curl -s -I localhost:8080/test.mp4
HTTP/1.1 200 OK
Date: Thu, 07 Sep 2017 14:48:14 GMT
Server: Apache
ETag: "6c0f3a-55899f81639c0"
Accept-Ranges: bytes
Content-Length: 7081786
Cache-Control: max-age=28800
Expires: Thu, 07 Sep 2017 22:48:14 GMT
X-Frame-Options: SAMEORIGIN
Content-Type: video/mp4



Safari loads the file (progress bar shows up) and autoplays it directly:

Webserver log:

- - - [07/Sep/2017:16:08:09 +0200] "GET /test.mp4 HTTP/1.1" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
- - - [07/Sep/2017:16:08:11 +0200] "GET /test.mp4 HTTP/1.1" 206 2 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
- - - [07/Sep/2017:16:08:11 +0200] "GET /test.mp4 HTTP/1.1" 206 7081786 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
- - - [07/Sep/2017:16:08:13 +0200] "GET /test.mp4 HTTP/1.1" 206 6669784 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"







Connecting through varnish with return(pass):

curl -s -I https://www.DOMAIN.org/test.mp4 | grep -v -E "key-pins|access-control|strict"
HTTP/2 200
date: Thu, 07 Sep 2017 14:48:59 GMT
etag: "6c0f3a-55899f81639c0"
accept-ranges: bytes
content-length: 7081786
cache-control: max-age=28800
expires: Thu, 07 Sep 2017 22:48:59 GMT
x-frame-options: SAMEORIGIN
content-type: video/mp4
x-varnish: 10
age: 0
via: 1.1 Cache


Safari starts to loading the file, progressbar does not shows any progress and video does not get autoplayed:


Varnish log:

IP - - [07/Sep/2017:16:12:04 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 2 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:04 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3076986 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:07 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3142462 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:12 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:03 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:58 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3207941 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:11 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3989392 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:14:13 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"




Webserver log:

IP - - [07/Sep/2017:16:12:03 +0200] "GET /test.mp4 HTTP/1.1" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:04 +0200] "GET /test.mp4 HTTP/1.1" 206 2 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:04 +0200] "GET /test.mp4 HTTP/1.1" 206 7081786 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:12:07 +0200] "GET /test.mp4 HTTP/1.1" 206 7049018 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:11 +0200] "GET /test.mp4 HTTP/1.1" 206 6983482 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:12 +0200] "GET /test.mp4 HTTP/1.1" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:57 +0200] "GET /test.mp4 HTTP/1.1" 206 6819642 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:13:58 +0200] "GET /test.mp4 HTTP/1.1" 206 6754106 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"
IP - - [07/Sep/2017:16:14:13 +0200] "GET /test.mp4 HTTP/1.1" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8"



Even pressing play manually, does not shows the video fluent. Instead a part is loaded and played (e.g. 2 seconds of the video) and then the playback stops again.

Sometimes I see a lot of sequent 64k-requests "GET /test.mp4 HTTP/1.1" 206 65536" while video is played partly. This happens only after a couple of time (more then 30 sec.) after the initial request.




> What do the developer tools tell you? Have you looked at varnishlog?


Developer tools of Safari does not tell something useful because media stuff is handled over to Quicktime ...



Are there more infos catchable that I am not aware of (tools of varnish etc.)?


--
Thank you,
Leon





_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
On Thu, Sep 7, 2017 at 5:10 PM, <info+varnish@shee.org> wrote:
<snip>
> Safari loads the file (progress bar shows up) and autoplays it directly:
<snip>
> Connecting through varnish with return(pass):
<snip>
> Safari starts to loading the file, progressbar does not shows any progress and video does not get autoplayed:

It might be a known bug when browsers ask for multiple ranges in a
single request, Varnish may serve the first one, disregard the rest
and think it is done, so that leaves the browser hanging waiting for
the rest of the response.

I think it you can work around that in VCL by detecting when you have
more than one range and return a 416 response.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
Am 07.09.2017 um 17:35 schrieb Dridi Boukelmoune <dridi@varni.sh>:
> It might be a known bug when browsers ask for multiple ranges in a
> single request, Varnish may serve the first one, disregard the rest
> and think it is done, so that leaves the browser hanging waiting for
> the rest of the response.

Thanks to pointing to this direction. Looking into it I see following (trimmed):

Request 1
ReqMethod GET
ReqURL /test.mp4
ReqHeader range: bytes=0-1

VCL_call HIT
RespStatus 200
RespReason OK
RespHeader Content-Length: 7081786
VCL_return deliver
RespHeader Accept-Ranges: bytes
RespHeader Content-Range: bytes 0-1/7081786
RespStatus 206
RespReason Partial Content
RespUnset Content-Length: 7081786
RespHeader Content-Length: 2


Request 2
ReqMethod GET
ReqURL /test.mp4
ReqHeader range: bytes=65509-7081785

VCL_call HIT
RespStatus 200
RespReason OK
RespHeader Content-Length: 7081786
VCL_return deliver
RespHeader Accept-Ranges: bytes
RespHeader Content-Range: bytes 65509-7081785/7081786
RespStatus 206
RespReason Partial Content
RespUnset Content-Length: 7081786
RespHeader Content-Length: 7016277


Seems to be mapped correctly, one range in one request. Also the response seems to be "valid" (adapted Content-Length).




> I think it you can work around that in VCL by detecting when you have
> more than one range and return a 416 response.


It seems to be related to the range handling in varnish, but the problem is not clearly right now.

Any other suggestions would be greatly appreciated.

--
Leon




_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
On Fri, Sep 8, 2017 at 2:55 PM, <info+varnish@shee.org> wrote:
<snip>
> Thanks to pointing to this direction. Looking into it I see following (trimmed):
>
> Request 1
> ReqMethod GET
> ReqURL /test.mp4
> ReqHeader range: bytes=0-1
>
> VCL_call HIT
> RespStatus 200
> RespReason OK
> RespHeader Content-Length: 7081786
> VCL_return deliver
> RespHeader Accept-Ranges: bytes
> RespHeader Content-Range: bytes 0-1/7081786
> RespStatus 206
> RespReason Partial Content
> RespUnset Content-Length: 7081786
> RespHeader Content-Length: 2
<snip>

Are those actual transactions originating from the browser or you
using a tool like curl to test the range behavior?

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
> Am 08.09.2017 um 17:05 schrieb Dridi Boukelmoune <dridi@varni.sh>:
>
> On Fri, Sep 8, 2017 at 2:55 PM, <info+varnish@shee.org> wrote:
> <snip>
>> Thanks to pointing to this direction. Looking into it I see following (trimmed):
>>
>> Request 1
>> ReqMethod GET
>> ReqURL /test.mp4
>> ReqHeader range: bytes=0-1
>>
>> VCL_call HIT
>> RespStatus 200
>> RespReason OK
>> RespHeader Content-Length: 7081786
>> VCL_return deliver
>> RespHeader Accept-Ranges: bytes
>> RespHeader Content-Range: bytes 0-1/7081786
>> RespStatus 206
>> RespReason Partial Content
>> RespUnset Content-Length: 7081786
>> RespHeader Content-Length: 2
> <snip>
>
> Are those actual transactions originating from the browser or you
> using a tool like curl to test the range behavior?


Its the real browser (Safari.app 10.1.2, Mac OS X 10.11.6 (15G1611)).
Indeed it seems to be strange requesting only 2 bytes initially.

A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on
the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another
dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before).

Does it make sense?

--
Leon


_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
Am 08.09.2017 um 18:54 schrieb info+varnish@shee.org:
> A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on
> the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another
> dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before).

Dridi, did you had time to assess this?

--
Thanks,
Leon


_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
On Wed, Sep 13, 2017 at 4:54 PM, <info+varnish@shee.org> wrote:
> Am 08.09.2017 um 18:54 schrieb info+varnish@shee.org:
>> A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on
>> the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another
>> dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before).
>
> Dridi, did you had time to assess this?

No, we kind of have a major release this week, I don't have time for
much. But if I had to bet I'd blame the h2 feature.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
> Am 13.09.2017 um 17:10 schrieb Dridi Boukelmoune <dridi@varni.sh>:
>
> On Wed, Sep 13, 2017 at 4:54 PM, <info+varnish@shee.org> wrote:
>> Am 08.09.2017 um 18:54 schrieb info+varnish@shee.org:
>>> A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on
>>> the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another
>>> dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before).
>>
>> Dridi, did you had time to assess this?
>
> No, we kind of have a major release this week, I don't have time for
> much. But if I had to bet I'd blame the h2 feature.


Thanks for the answer. Looking forward for the next release :-)

--
Leon

_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
>>> Dridi, did you had time to assess this?
>>
>> No, we kind of have a major release this week, I don't have time for
>> much. But if I had to bet I'd blame the h2 feature.
>
>
> Thanks for the answer. Looking forward for the next release :-)

Hi Leon,

Did you try playing videos using HTTPS without enabling h2? As of
5.2.0 it is still experimental.

Thanks,
Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
> Am 18.09.2017 um 10:25 schrieb Dridi Boukelmoune <dridi@varni.sh>:
>
>>>> Dridi, did you had time to assess this?
>>>
>>> No, we kind of have a major release this week, I don't have time for
>>> much. But if I had to bet I'd blame the h2 feature.
>>
>> Thanks for the answer. Looking forward for the next release :-)
>
> Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental.


Yes, that is what I have deployed now. Without h2 enabled it works as expected
(hitch; alpn-protos = "http/1.1). Doing so I lose a bit of site performance but
the functional requirement playing media is higher scored.

Right now rolling 5.2.0 packages, just to stay current (h2 stuff seems to be untouched).

--
Thanks
Leon












_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
>> Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental.
>
>
> Yes, that is what I have deployed now. Without h2 enabled it works as expected
> (hitch; alpn-protos = "http/1.1). Doing so I lose a bit of site performance but
> the functional requirement playing media is higher scored.
>
> Right now rolling 5.2.0 packages, just to stay current (h2 stuff seems to be untouched).

Thanks for confirming, so we narrowed it down to what looks like a
range bug with h2. Can you open a github issue? We'll pick it up from
there and try to reproduce it.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Handling HTML5 Video for iOS and Safari clients [ In reply to ]
> Am 20.09.2017 um 12:21 schrieb Dridi Boukelmoune <dridi@varni.sh>:
>
>>> Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental.
>>
>>
>> Yes, that is what I have deployed now. Without h2 enabled it works as expected
>> (hitch; alpn-protos = "http/1.1). Doing so I lose a bit of site performance but
>> the functional requirement playing media is higher scored.
>>
>> Right now rolling 5.2.0 packages, just to stay current (h2 stuff seems to be untouched).
>
> Thanks for confirming, so we narrowed it down to what looks like a
> range bug with h2. Can you open a github issue? We'll pick it up from
> there and try to reproduce it.

https://github.com/varnishcache/varnish-cache/issues/2473

--
Thanks
Leon
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc