Bug 221622 – [GStreamer] Cannot play most videos: Received unexpected 200 HTTP status code for range request

• Status: REOPENED
• Component: Media

[Michael Catanzaro]

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.

[Alicia Boya García]

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.

[Michael Catanzaro]

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.

[Alicia Boya García]

(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).

[Philippe Normand]

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?

[Alicia Boya García]

(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.

[Noam Rosenthal]

See HTML PR: https://github.com/whatwg/html/pull/7782
and WPT: https://github.com/web-platform-tests/wpt/pull/33491

[Philippe Normand]

(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.

[Michael Catanzaro]

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

[Philippe Normand]

(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.

[Philippe Normand]

Ah, sorry, somehow I had it in cache...

[Michael Catanzaro]

*** Bug 263718 has been marked as a duplicate of this bug. ***

[Philippe Normand]

Pull request: https://github.com/WebKit/WebKit/pull/19687

[Sergio Villar Senin]

Another example is the video in https://release.gnome.org/45 which URL is https://release.gnome.org/45/loupe.webm

[Carlos Bentzen]

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.

[Michael Catanzaro]

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.
"""