Karma webserver fails to properly serve mp3 files

[gregor]

For a few of our unit tests I tried to set up audio elements and play them. The promise that Chrome returns on HTMLAudioElement.play() returns always rejects with a 'no available source' error. As far as I can tell the Karma web server that I configured to serve my mp3 files using the files pattern and required proxy does not properly serve the file.

I then kept the karma webserver alive using the singleRun: false flag and tried to access the file directly from Chrome at http://localhost:9876/audio/{filename}.mp3.

Expected behavior

The browser should be able to play the sound.

Actual behavior

The mp3 file is found. Webserver therefore seems to be properly configured. It is never able to play the file though. Audio.readyState stays at 0: HAVE_NOTHING.

Comparing the request to the mp3 file with one to our regular dev environment that is opening up the server via grunt-contrib-connect I notice a few differences. The response headers include connection: closedespite a request for keep-alive. It is missing a content-length header but contains transfer-encoding: chunked.

Also the nocache option of the file pattern seems to be ignored as the mp3 is served with cache-control: no-cachand pragma: no-cache headers.

Enviroment Details

• Karma version 1.2.0
• Relevant part of your karma.config.js file

browsers: ['Chrome'],
files: [
      {pattern: 'audio/*.mp3', included: false, served: true, nocache: false}
    ],
proxies: {
      '/audio/': '/base/audio/'
},
singleRun: false

[kahwee]

I have the same issue and fixed this in #2315. More information in #2310. It doesn't work for Chrome.

[gregor]

@kahwee Indeed. Missed your issue as it was already closed. Thanks for pointing me to your fix. For now until your fix is part of a release I have downgraded Karma and my tests run just fine.

[wesleycho]

Looks like the fix for this has already been released, so this can probably be closed now.

[maksimr]

Close as duplicate #2310

Feel free reopen
Thanks