221622 2021-02-09 11:59:24 -0800 [GStreamer] Cannot play most videos: Received unexpected 200 HTTP status code for range request 2024-04-30 09:19:28 -0700 1 1 1 Unclassified WebKit Media WebKit Nightly Build PC Linux REOPENED https://bugs.webkit.org/show_bug.cgi?id=183259 P2 Normal --- 1 mcatanzaro philn aboya bugs-noreply cadubentzen calvaris fjimenez mcatanzaro noam philn pnormand svillar oldest_to_newest 1727163 0 mcatanzaro 2021-02-09 11:59:24 -0800 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. 1727235 1 aboya 2021-02-09 14:02:50 -0800 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. 1727295 2 mcatanzaro 2021-02-09 15:07:34 -0800 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. 1727482 3 aboya 2021-02-10 02:19:55 -0800 (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). 1792441 4 pnormand 2021-09-10 10:45:12 -0700 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? 1792665 5 aboya 2021-09-11 01:29:14 -0700 (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. 1857823 6 noam 2022-04-04 05:41:24 -0700 See HTML PR: https://github.com/whatwg/html/pull/7782 and WPT: https://github.com/web-platform-tests/wpt/pull/33491 1958862 7 philn 2023-05-30 13:18:29 -0700 (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. 1964047 8 mcatanzaro 2023-06-28 09:28:43 -0700 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 1964048 9 philn 2023-06-28 09:32:22 -0700 (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. 1964049 10 philn 2023-06-28 09:36:46 -0700 Ah, sorry, somehow I had it in cache... 1987731 11 mcatanzaro 2023-10-26 08:17:43 -0700 *** Bug 263718 has been marked as a duplicate of this bug. *** 1988303 12 pnormand 2023-10-29 03:02:14 -0700 Pull request: https://github.com/WebKit/WebKit/pull/19687 2015434 13 svillar 2024-02-20 01:06:24 -0800 Another example is the video in https://release.gnome.org/45 which URL is https://release.gnome.org/45/loupe.webm 2024187 14 cadubentzen 2024-03-27 08:34:11 -0700 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. 2032231 15 mcatanzaro 2024-04-30 09:19:28 -0700 Just a note, from https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests """ Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. """