Issues with range requests on Safari/iOS

[amazeika]

Requests with range headers seem to be failing when the webserver is running http/2.

Until we find the reason why they fail, we may disable range headers support if the webserver is running http/2.

See:

• https://support.joomlatools.com/tickets/topic/9989
• https://support.joomlatools.com/tickets/topic/9923
• https://support.joomlatools.com/tickets/topic/11436
• https://support.joomlatools.com/tickets/topic/11458-cannot-playback-mp3s-on-the-iphone
• https://support.joomlatools.com/tickets/topic/13701

[johanjanssens]

@amazeika I'll handle this one for you.

[johanjanssens]

@amazeika @stevenrombauts Do you have any information how we can replicate this locally. I would need to be able to enable http/2 on the box?

[stevenrombauts]

@johanjanssens These 4 commands should enable HTTP/2 in Apache on the box: https://github.com/joomlatools/joomlatools-vagrant/issues/146#issuecomment-497441587

but I have only tested this on the new box (WIP) so maybe there is something different on your box copy. If it doesn't work, please copy the output of the error log (/var/log/apache2/error.log) on Slack so I can take a closer look or just wait a little bit until we roll out the new version (in the coming days)

[amazeika]

@johanjanssens Once http /2 is enabled (I've used similar steps as provided by @stevenrombauts for this end) you just add a video and you'll see that DOCman is just unable to estimate the total length of the file due to range headers failling. If the fix is good, then you'll be able to see the video length in the progress bar while on http /2. Double check the protocol being used with the inspector.

Another important thing, make sure to access the site using https, as http /2 won't kick otherwise :)

Please let me know how it goes man.

[johanjanssens]

@amazeika @ercanozkaya The idea was that if we couldn't find the cause and a way to fix it to turn range headers off for HTTP/2. To that end this ticket includes changes to recognise http/2 and make the framework aware of a http/2 request. I have however not turned off range request.

Accoording to: https://http2.github.io/http2-spec/#rfc.section.8

Thus, the specification and requirements of HTTP/1.1 Semantics and Content [RFC7231], Conditional Requests [RFC7232], Range Requests [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are also applicable in HTTP/2, but the expression of those semantics for this protocol are defined in the sections below.

Which seems to indicate that Range headers work fine with http/2. This makes me believe that this problem is not us, but the combination of video player + http/2.

What i would do is, check if this problem happens with other video players too. It seems that this issue was reported as a video player on iphone/apple not working on http/2 using range headers

So you can either turn off range headers on http/2, or you can turn them off for apple devices only on http/2. We have also not yet confirmed that no range headers on http/2 actually works.

[johanjanssens]

Can we nail this down too:

• Is video with range headers on http/2 failing everywhere
• Is video with range headers on http/2 failing on apple
• Is video on http/2 working?

[johanjanssens]

@amazeika @jebbdomingo Can you please go here: https://support.joomlatools.com/tickets/topic/11458-cannot-playback-mp3s-on-the-iphone and test using the setup provided?

This is all working on my end both iOS and Desktop, bot Chrome and Safari.

[johanjanssens]

I tested the customer's staging site https://testj.walkwithmenow.com/index.php/library/ios with the following:

1. Desktop Chrome 95
2. Desktop Safari 14.1.2
3. iOS 14.8 Chrome 81
4. iOS 14.8 Safari

Additional notes; the above site is working both in the player (in DOCman UI) and when the link is used directly in the browser. Tested both.

[jebbdomingo]

I tested the customer's staging site http://testj.walkwithmenow.com/index.php/library/ios with the following:

1. Safari iPhone iOS 15.1
2. Safari iPad 8th Gen iPadOS 14.4.2
3. Chrome 95.0.4638.50 on iPhone iOS 15.1
4. Google Chrome Version 95.0.4638.69 (Official Build) (x86_64) on macOS Big Sur Version 11.6
5. Safari Version 15.0 (16612.1.29.41.4, 16612) on macOS Big Sur Version 11.6
6. Firefox 94.0.1 (64-bit) on macOS Big Sur Version 11.6

[johanjanssens]

@jebb @arunas can you also do a test for https://support.joomlatools.com/tickets/topic/9989 with url: https://www.selmer.at/katalog/produkte/falk/9220-falk-chair-edit-10-hd-2-mp4/file.html

[johanjanssens]

Tests for https://www.selmer.at/katalog/produkte/falk/9220-falk-chair-edit-10-hd-2-mp4/file.html

I only can get this working on Chrome. It's not working on iOS, even in Chrome.

[johanjanssens]

More info: https://stackoverflow.com/questions/50168709/html-video-not-playing-in-safari-browser and https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6

I performed following two tests:

• curl --range 0-99 https://www.selmer.at/katalog/produkte/falk/9220-falk-chair-edit-10-hd-2-mp4/file.html -o /dev/null
• curl --range 0-99 https://www.selmer.at/katalog/produkte/falk/9220-falk-chair-edit-10-hd-2-mp4/file.html -o /dev/null --http1.1

Error: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Based on this it seems that the problem is badly configured http/2 support on the server. Chrome might be retrying on http1.1, or neglecting the issue while Safari (and or iOS) blocks the request/response.

Problem found

See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive

The response is containing a 'Connection: Keep-Alive' header. Safari is blocking the request when the response contains a header that is forbidden for http2.

[johanjanssens]

Related issue report on Gitlab: https://gitlab.com/gitlab-org/gitlab-pages/-/issues/504