Bug 267418 – Safari sporadically not sending HTTP cookies on 2nd media request, sometimes resulting in failed playback

• Component: Media
• Status: NEW

I can't replicate this consistently, but we've had customers report this and I've witnessed it firsthand.

When playing an MP3 via the standard HTML5 audio element, Safari makes two requests: the first one with a range of 0-1, then a second one with a range of 0 up to the full size of the MP3. With our particular setup, the MP3 files are hosted on AWS S3 behind CloudFront, and requests for these files will only work when a valid CloudFront signed cookie (HTTP cookie) is passed along with the request.

In most cases, this works fine, but under some unknown circumstances, that second request will not include AWS CloudFront signed cookies, and so the request fails. I was remotely connected to a customer's Mac, and saw the two HTTP requests for the MP3. The first one included the HTTP cookies, the second request for the full MP3 did not.

If any devs on the WebKit team have a hunch as to what might be causing this, so I can replicate it more consistently, please let me know!

[Alexey Proskuryakov]

Thank you for the report! Would it be possible to make a publicly accessible test where we could reproduce this, even if occasionally?

Also CC;ing some people who might have an idea.

Yep, here you go:

https://play.reelcrafter.com/example/demo-reel-composer

Just play any audio track. I'll connect with one of our customers who had this issue, and see if I can get a screenshot showing the issue.

[Alexey Proskuryakov]

Created attachment 469384 [details]
inspector screenshot

This seems pretty easy to reproduce, I see this every time I try on macOS Sonoma 14.3 beta.

1. Load https://play.reelcrafter.com/example/demo-reel-composer
2. Click on the play button.
3. After it starts playing, click on "A Turning Point" below.

Results: some of the mp3 requests in Web inspector show up as failed loads, and there is no cookie in request.

I didn't notice any observable misbehaviors though, aside from failures in Web Inspector. Is there some aspect of this that makes it a substantial problem?

Created attachment 469386 [details]
Recording showing cookie headers missing in request

Yes, this is the issue. Note the requests in red, and if you look at them, they are not passing the HTTP cookies to the server. This is problematic, because like I said, the content is secured on AWS behind CloudFront, and it's expecting those HTTP cookies to permit the client to fetch media from the S3 bucket.

[Alexey Proskuryakov]

It's understood that the request is failing. I'm trying to understand the impact for prioritization purposes. It looks like the website works perfectly well, as a retry at some level succeeds at fetching the MP3. 

Is there anything substantially bad here that makes this worth prioritizing higher?

Right, so the part that makes this a major issue (and the sporadic part that's hard to track down) is that sometimes that failed network request will actually raise an error to the client, causing the track to not be played. And this part of our code is triggered:

    if (
      e.name === 'AbortError' /* before Safari 12 */ ||
      e.name === 'NotAllowedError' /* Safari 12+, other browsers */
    ) {
      // Somehow blocked, despite our best efforts :(
      this.emit('error', e, {
        error: 'PLAY_BLOCKED',
        message: 'Playback blocked by browser',
        lastRequestedUrl: this.lastRequestedUrl,
        playerSrc: this.audioEl.src,
      });

I can never replicate this, and it happens to our customers occasionally. When I remoted into a customer's machine (while this error was occurring), the only strange thing I saw was that the HTTP cookies weren't being sent in the request, so I figured that was the issue, or it's at least related somehow.

[Radar WebKit Bug Importer]

<rdar://problem/121015082>