Interesting, we have a similar discussion on  issue 606666 . Do you know when this behavior regressed? I.e. does M49 work properly for you? There aren't any media-side network changes I'm aware of in M50 that should cause this.

I can' repro - we're pulling the redirect out of the cache when I seek in the video:

t=2698 [st=   1]   +URL_REQUEST_START_JOB  [dt=3]
                    --> load_flags = 33024 (MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> priority = "LOWEST"
                    --> url = "https://player.vimeo.com/external/..."
t=2698 [st=   1]      URL_REQUEST_DELEGATE  [dt=0]
t=2698 [st=   1]      HTTP_CACHE_CALLER_REQUEST_HEADERS
                      --> Accept-Encoding: identity;q=1, *;q=0
                          User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36
                          Range: bytes=1081398-
                          Accept: */*
                          Referer: https://fiddle.jshell.net/...
                          Accept-Language: en-US,en;q=0.8
                      --> line = ""
t=2698 [st=   1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=2698 [st=   1]      HTTP_CACHE_OPEN_ENTRY  [dt=1]
t=2699 [st=   2]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=2699 [st=   2]      HTTP_CACHE_READ_INFO  [dt=1]
t=2700 [st=   3]      URL_REQUEST_DELEGATE  [dt=0]
t=2700 [st=   3]     +URL_REQUEST_DELEGATE  [dt=1]
t=2701 [st=   4]        DELEGATE_INFO  [dt=0]
                        --> delegate_info = "AsyncResourceHandler"
t=2701 [st=   4]     -URL_REQUEST_DELEGATE
t=2701 [st=   4]      URL_REQUEST_REDIRECTED
                      --> location = "https://fpdl.vimeocdn.com/vimeo-prod-skyfire-std-us/...."
t=2701 [st=   4]   -URL_REQUEST_START_JOB

Note that we never go over the network, we just look up the entry from the cache and follow the redirect.  In the inspector, I'm also seeing "Status Code:302 Found (from cache)"

I'm using Chrome 50.0.2661.86, on Windows.

Could you please provide a net-internals log of this happening?  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Here is a net-internals log. It is quite large, but I was able to reproduce the issue. On OS X Chrome 50 I am definitely not seeing the (from cache). I can also see that the vimeocdn.com url we get is different every time.

Deleted: net-internals-log.json 9.3 MB

net-internals-log.json 9.3 MB View Download

You have to scroll down quite a ways in the log to start seeing the new tokens on the fpdl.vimeocdn.com URLs, but they are in there.

Thanks for the log!  Those requests are using the load flag "BYPASS_CACHE", which explains why the responses aren't being pulled from the cache.  Unclear why that flag is being added to the request.

What extensions do you have installed?

The issue doesn't sound like an extension, but best to verify that by turning them all off, and seeing if you still have the issue.

The dev console has a a "disable cache" checkbox, is it checked?

Just tried in a guest browsing window with all extensions disabled. Disable cache is not checked. Able to reproduce.

One thing to note is if I seek forward in the video I do not see any new requests in the network panel (even when seeking to unbuffered ranges), but when I seek backwards to a part that was already played that's when it starts re-requesting the original player.vimeo.com url. Once it gets in that state it will start requesting it with every seek.

(Completely unrelated but we are having an outage now on player.vimeo.com so it won't be reproducible for anyone until we figure this out)

I think we are back

And just to confirm, I've tried going back and forth in the video, with devtools open, and can't repro.

Seems like whatever is adding that flag is outside the network stack, most likely in the renderer process, which is beyond my knowledge.

[hubbe, dalecurtis]: Can either of you repro?

MMenke; if you'r using a ToT, canary or dev build, you might need to specify --disable-features=use-new-media-cache to get the same behavior as current release builds from the media stack. When "use-new-media-cache" is in effect, we use the redirected url for seeks, and it doesn't matter if the network stack caches the result or not. However, we never use BYPASS_CACHE, regardless of "use-new-media-cache".

I'm using stable.  I am seeing us request the original URL, and getting the redirects, but they're being pulled from the cache, and we're not using the BYPASS_CACHE flag, unlike in iamcraigcampbell's logs.  I am on Linux, not windows, which could make a difference...but attaching load flags based on platform seems unlikely to me.

For completeness I tried M49 & M50 on Windows & Mac, all behaved the same way as #13.

So I just tested this, and I also am no longer to reproduce. I must have had the “Disable Cache” checked. Sorry for the false alarm!

Just to clarify from comment #12 does that mean the behavior I brought up in  issue 102201  will actually be the default behavior going forward? So we do not need to return Cache-Cotnrol anymore?

The standard is actually unclear on what the right behavior is. As far as we can tell, it's permitted, but not required for the browser to use the redirected url on a seek. It's likely, but not certain that chrome will be using the redirected URL when a seek occurs in the future. You should keep the cache-control header though, as other browsers may behave differently.

Closing the bug as not reproducible.