1097508 - Firefox caches HTML5 video source URL temporal redirects

Status: UNCONFIRMED

(Core :: Audio/Video: Playback, defect, P3)

Description

[masterit.dev]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141106120505

Steps to reproduce:

The HTML 5 video tag contains source sub-element. That element points to some URL (base URL). The service at this URL executes some logic and sends 302 redirect to the browser.


Actual results:

Firefox follows the redirect and sends request to the second URL. The second URL streams the video and it is available for Range requests. For the next HTTP Range requests (if any), Firefox uses the second URL directly, i.e. the browser uses the base URL only once per video, at the very beginning. All following Range requests are sent directly to the second URL. Is this proper behavior according to the HTTP specification? Injecting ‘Cache-Control’: ‘no-cache, no-store’ response headers does not make any difference.


Expected results:

Each HTTP Range request shall use the base URL specified in the HTML 5 video source element.

Comment 1

[Matthias Versen [:Matti]]

>Injecting ‘Cache-Control’: ‘no-cache, no-store’ response headers does not make any difference.
Just to be sure: did you inject the headers at the 302 ?

moving to video/audio because I think it's the source of the range-requests

Comment 2

[masterit.dev]

Yes, the headers are injected at the 302 Redirect response.

Comment 3

[Avi]

Encountered this annoying bug today with 35.0.1.
First URL response has:
HTTP/1.1 302 Moved Temporarily
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

But then it always go directly to the second URL (the one the first URL redirects to).

Comment 4

[Cristofer Almeyda]

Hello, I just found this bug, It is really important to us find a way to fix this, We have a plataform of video streaming and we need use signed urls, we use a link to generate the url, all works fine is other browsers but firefox don't, in firefox takes a url and keep it for next request and takes many tries to get connect.
Anyone get a solution for this?

Comment 5

[José Bateira]

Same issue here.
I'm sending "cache-control: no-cache, private, no-store, must-revalidate, max-age=0" in the original URL and the second URL to no avail.

Any updates on this?

Comment 6

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Can someone provide a link that reproduces this issue?

Comment 7

[José Bateira]

Attachment: nodejs_sample.zip

According to the spec:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8
"The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field."

Given this, when a video/audio element is loaded with a source URL that is a redirect, it should not cache that result. But it does. Firefox keeps using the redirected URL.
As I said before, I am sending "Cache-Control: no-cache, private, no-store, must-revalidate" in the response headers.

I encountered this issue because I have signed URLs for streaming that are valid for a short period of time.
I have attached a sample nodejs express server that very mildly reproduces my backend strategy.

Steps to run sample and reproduce the issue:

1. Install nodejs (https://nodejs.org/)
2. Download code sample to a folder
3. Download a video sample for the test and copy it to the folder. (e.g. https://mega.nz/#!dZkQBbgY!QAv0Vueqri2rUQW0unhYqOCS_O0HB222ukO9WZ_eJXA)
3. cd to folder and run "$ npm install"
4. Start server: "$ node index"
5. Open "http://localhost:3000" in firefox
6. Wait at least one second after the video loads and then seek to any unbuffered range using the seek bar of the native player.

Expected Results: The seek should take me to the desired point and continue streaming.

Actual Results: The video crashes, since the signed URL only lasts 1 second.
You can verify the stdout logs of the server and see that only one redirect was done at the start, and from then on, only direct requests to the redirected URL were made.
What should always happen is: a redirect always followed by the redirected URL (you can see this behaviour in chrome).

Notes: Although the given code sample is using a video, this also happens with audio elements.

FYI Safari also has this issue.
Chrome does not have this issue: it always performs the original request for a redirect.

Please note that if I remove the "src" attribute from the element, on seek for example, and add it again, the problem does not occur: the requested URL is the original one.
To demonstrate this you can use the custom slider below the native player.

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3