[swd847]

You should configure it via expression filter:

<filters>

  <expression-filter name="range" expression="byte-range(send-accept-ranges=true)" />

</filters>

It looks like there is a bug in Wildfly, as this should not actually be required if you are using the default servlet to serve content, it looks like org.wildfly.extension.undertow.deployment.ServletResource does not implement RangeAwareResource.

[jasonholmberg]

Thanks Stuart.  That did work to configure the filter, although the filter did not seem to fix my issue. Perhaps I need to create a new forum posting for this problem.  But here it is anyway.  As mentioned earlier, before getting distracted by filter configuration, I am having trouble serving video content (video/mp4 or anything else for that matter) to Safari from WildFly. Other browsers work.  And the same app works serve the content to Safari when served from Tomcat.

Here is a small project to demonstrate the problem: https://github.com/slowtrailrunner/html5-vidtest

Anyone have any ideas.

[jasonholmberg]

This is the result of a request to WildFly with apparently the Range headers enabled:

$ curl -I --range 0- http://localhost:8880/vidtest/vidtest.mp4

HTTP/1.1 200 OK

Connection: keep-alive

Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT

X-Powered-By: Undertow/1

Server: WildFly/10

Content-Type: video/mp4

Content-Length: 8200890

Date: Fri, 18 Mar 2016 16:59:55 GMT

This is the result of a request to the same content being served from Tomcat 8:

$ curl -I --range 0- http://localhost:8080/vidtest/vidtest.mp4

HTTP/1.1 206 Partial Content

Server: Apache-Coyote/1.1

Accept-Ranges: bytes

ETag: W/"8200890-1458232627000"

Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT

Content-Range: bytes 0-8200889/8200890

Content-Type: video/mp4

Content-Length: 8200890

Date: Fri, 18 Mar 2016 17:00:08 GMT

To me this suggests that the ByteRangeHandler might not been handling the request correctly.

The "--range 0-"  simulated the kind of request Chrome makes for this sort of content with a "Range: 0-" header.

Note: the "-I" flag on the curl call is a capitol I - pronounced "eye" and not a lower case letter L.

[jasonholmberg]

I have created a JIRA for what seems to be a problem with how the range requests are handled: [WFLY-6413] Range headers do not seem to be handled correctly and prevents video delivery in Chrome and Safari - JBoss I…

[swd847]

I forgot to mention in my other post but you also need to include a fliter-ref on the relevant host to actually enable the filter:

<filter-ref name="range" />

[swd847]

Looks like there is a bug in the byte-range handler where it does not respond to head requests (only get). I will fix.

[jasonholmberg]

Hmm, I think perhaps my curl example was misleading (it was inadvertently making HEAD requests).  Regardless of how the byte-range handle was (or was not) responding to HEAD requests,  I think there is still an issue with GETs.  This 'curl' example issues GETs. And I am hitting a patched local version of WildFly that included your fix for [UNDERTOW-664] Byte ranger handler does not handle HEAD requests - JBoss Issue Tracker.

GET Request to patch WildFly

$ curl -sD - -o /dev/null --range 0- http://localhost:8880/vidtest/vidtest.mp4

HTTP/1.1 206 Partial Content

Connection: keep-alive

Last-Modified: Thu, 17 Mar 2016 19:15:42 GMT

X-Powered-By: Undertow/1

Content-Range: 0-8200889/8200890

Server: WildFly/10

Content-Type: video/mp4

Content-Length: 8200890

Date: Tue, 22 Mar 2016 15:01:57 GMT

Identical GET request to Tomcat 8

$ curl -sD - -o /dev/null --range 0- http://localhost:8080/vidtest/vidtest.mp4

HTTP/1.1 206 Partial Content

Server: Apache-Coyote/1.1

Accept-Ranges: bytes

ETag: W/"8200890-1458232627000"

Last-Modified: Thu, 17 Mar 2016 16:37:07 GMT

Content-Range: bytes 0-8200889/8200890

Content-Type: video/mp4

Content-Length: 8200890

Date: Tue, 22 Mar 2016 15:04:16 GMT

Notice that WildFly (undertow) is still not responding with the Accept-Ranges header and I think it probably should be.

[heinminhsoe]

Hi Jason, did you solve the problem.

I'm also having same problem, can't solve anyhow.

[jon.morgan]

I had this problem of video  (HTML video) not playing on Apple when using Wildfly 10.0.0

I changed to Wildfly 10.1.0 and it now works.

[oswulf]

Recently, i am looking into an issue that the video playback does not work properly on chrome. I am able to play the video on chrome and the time seeking function does not work as expected. After doing some research from the web, i realized that this problem is related to byte serving and it somehow brought me to this thread. I am currently running on WildFly 10.1.0.Final and it does not work for me. If i read this thread correctly based on Jason's earlier reply, CURL should return HTTP 206 but i am still getting HTTP 200. Did i missed any configuration on WildFly 10.1.0.Final to make this works?

Below is the results from CURL on a ~4MB video:

curl -H Range:bytes=0-100 -I  http://127.0.0.1:8080/sample/downloadContent?contentId=8a84a1f4656a007501656aedd96911f4

HTTP/1.1 200 OK

Connection: keep-alive

X-Powered-By: Undertow/1

Server: WildFly/10

Content-Type: video/mp4

Content-Length: 3414439

Date: Fri, 21 Sep 2018 09:23:15 GMT