Issues with range requests on Safari/iOS #549
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…quests are working. If the response contains Content-Length this request fails.
|
@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. |
|
@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. |
|
@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. |
|
@jebbdomingo @amazeika Thanks for testing. I will do more work on this. |
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/nullBefore 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.