Splitting this out of bug #183259. I am unable to play this video in Element: https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4 Phil says the problem is: ERROR webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:1806:handleMessage: Error 9: R3: Received unexpected 200 HTTP status code for range request (url=https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4) Calvaris says: > AFAIK a working range request should answer 206, not 200. > > If we should accept 200 as a valid answer and be prepared to handle the whole download is a different issue.
Note: * An HTTP server serving media files should support range requests and Content-Length. Otherwise data seeks are impossible, which media players and browsers (not only WebKit) expect to be able to do. * Safari will outright mark these videos as broken for this reason. Implications of supporting broken servers that lack range requests: * The only way to support this is by downloading the entire file from byte zero, either to memory or to disk. * This adds extra complexity to WebKitWebSrc. * Because of the layout of very common media files (e.g. non-fragmented MP4 files with a trailing moov, the most common kind of MP4 files) many files won't be able to play until the entire file has been downloaded. * Users will assume this is a correct configuration seeing how small videos work, but later complain that playback or seeks are very slow, or about strange disk/memory usage. Therefore, please note that the real problem here is in the server-side. This is at its core not a WebKit bug, but a server bug. A workaround in WebKit to accomodate broken servers is technically possible, with all these caveats and some open questions, such as what to do if the video is "too big" (which in the case of a missing Content-Length it may not even be known in advance). Personally I wouldn't give it a high priority unless there were important websites with broken configurations like this.
I'll trust you experts to decide what to do! Suffice to say this video works perfectly in Firefox. It would be good to report a bug to Element if we decide not to change WebKit.
(In reply to Michael Catanzaro from comment #2) > I'll trust you experts to decide what to do! Suffice to say this video works > perfectly in Firefox. > > It would be good to report a bug to Element if we decide not to change > WebKit. It would be good to report to Element regardless, since browser support would only be possible with a workaround (as explained).
Reading this: https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.content-range If the server ignores a byte-range-spec because it is syntactically invalid, the server SHOULD treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing the full entity). If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected resource), it SHOULD return a response code of 416 (Requested range not satisfiable) (Section 3.2). Note: Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for an unsatisfiable Range request-header, since not all servers implement this request-header. ... So, do I understand correctly that we should expect 200 (OK) when the server wasn't able to fullfil the range request?
(In reply to Philippe Normand from comment #4) > ... So, do I understand correctly that we should expect 200 (OK) when the > server wasn't able to fullfil the range request? Yes. Which makes sense because that's what a naive server that doesn't check for the Range header will do.
See HTML PR: https://github.com/whatwg/html/pull/7782 and WPT: https://github.com/web-platform-tests/wpt/pull/33491
(In reply to Noam Rosenthal from comment #6) > See HTML PR: https://github.com/whatwg/html/pull/7782 > and WPT: https://github.com/web-platform-tests/wpt/pull/33491 Sadly this test doesn't seem to cover the issue at hand. After adding the missing asset (https://github.com/WebKit/WebKit/pull/14504) the test is passing here in GTK, without patching our httpsrc element.
More videos that I believe are broken due to this bug (from bug #183259): https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ https://bugs.webkit.org/attachment.cgi?id=451573
(In reply to Michael Catanzaro from comment #8) > More videos that I believe are broken due to this bug (from bug #183259): > > https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ As mentioned in the other bug, that one plays here now.
Ah, sorry, somehow I had it in cache...
*** Bug 263718 has been marked as a duplicate of this bug. ***
Pull request: https://github.com/WebKit/WebKit/pull/19687
Another example is the video in https://release.gnome.org/45 which URL is https://release.gnome.org/45/loupe.webm
Commenting here just for completeness in case someone looks at this in the future. (In reply to Michael Catanzaro from comment #0) > https://gnome.modular.im/_matrix/media/r0/download/gnome.org/ > 62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4 This server does respond with 206 to range requests now, so they might have fixed it. (Was a bug filed?) ``` $ curl -v https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4 -H 'Range: bytes=0-' -O ... > GET /_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4 HTTP/2 > Host: gnome.modular.im > User-Agent: curl/8.2.1 > Accept: */* > Range: bytes=0- < HTTP/2 206 < date: Wed, 27 Mar 2024 15:06:11 GMT < content-type: video/mp4 < content-length: 2404245 < accept-ranges: bytes < access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization < access-control-allow-origin: * < cache-control: private, max-age=259200 < content-disposition: inline; filename=video_514ec09.mp4 < content-range: bytes 0-2404244/2404245 < content-security-policy: sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; media-src 'self'; object-src 'self'; < cross-origin-resource-policy: cross-origin < x-content-security-policy: sandbox; < x-rate-limit-duration: 1 < x-rate-limit-limit: 10.00 < x-rate-limit-request-forwarded-for: 84.157.74.81 < x-rate-limit-request-remote-addr: 172.17.0.144:33106 < x-robots-tag: noindex, nofollow, noarchive, noimageindex < strict-transport-security: max-age=15724800; includeSubDomains ``` The reason it doesn't play now is also in the HTTP response and shows in the inspector console: ``` CONSOLE SECURITY ERROR Blocked script execution in 'https://gnome.modular.im/_matrix/media/r0/download/gnome.org/62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. ``` It played for me after patching ScriptController::canExecuteScripts(). No idea whether this is a bug or WebKit is actually more correct here. (In reply to Michael Catanzaro from comment #0) > Phil says the problem is: > > ERROR webkitmediaplayer > MediaPlayerPrivateGStreamer.cpp:1806:handleMessage: Error 9: R3: Received > unexpected 200 HTTP status code for range request > (url=https://gnome.modular.im/_matrix/media/r0/download/gnome.org/ > 62a43e4dd1f71c657be994f79a4a203db9c9e708/video_514ec09.mp4) > Can still reproduce this in today's trunk with: - https://release.gnome.org/45/loupe.webm - https://bugs.webkit.org/attachment.cgi?id=451573 With https://teams.pages.gitlab.gnome.org/Design/web-experiments/static/tiling/ the video does play, but stalls at ~7s.