Issues with range requests on Safari/iOS

[github-actions[bot]]

This PR Closes #277 and tries to fix issues with media streaming on Safari/iOS. Safari/iOS handles http2 response headers more strictly.

Changes

• The spec states the http range requests can return a content-length header but this header should contain the length of the range being requested. To ensure this is the case the code no longer sends a content-length header by default when doing streaming requests, this header would contain the complete length of the file and that goes against the spec.

• Safari sends an initial 0-1/xxxx range request to test if the server can handle range requests correctly. It seems that if the response to this request contains a content-length Safari will not accept the response.

Its unclear if this is a Safari issue, or a more broader http2 issue. This problem can also be tested when using curl:

curl --range 0-1 "http://example.com/file" -o /dev/null

Before the changes this request results into a curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) error, while after the changed the request completes without errors.

[amazeika]

@johanjanssens Tried these changes on my end (locally) and it does not sort it out for me. In fact adding this breaks all media playback when using http/1.1 on Safari desktop which works otherwise.

[amazeika]

@johanjanssens Spent a couple of hours yesterday night looking for some more info about Safari failing during these requests ... nothing very concrete but this all that I read, and the fact that curl also reports a problem, leans towards a problem with the server itself and the way it delivers the response. Not 100% convinced that this is a problem with Safari or Curl, instead Chrome and FF are probably more forgiving and do the necessary to process the response.

See you on Monday man.

[amazeika]

@johanjanssens This morning I wend ahead and installed a Homestead instance which is another box commonly used for Laravel development. The idea was to test this on a different environment than ours and see if I get a different behavior.

After setting it all up, I got the exact same results. The fix doesn't work for me and it ends up breaking the http/1.1 playback as well on Safari Desktop.

I also tried the same on Nginx, I get the same results as I do on Apache.

[johanjanssens]

@jebbdomingo @amazeika Thanks for testing. I will do more work on this.