Cache busting parameter on manifest requests

[Feenposhleen]

This causes issues on at least one CDN that we use with tokenized protection. They expect manifest request GETs to match very specific rules (might be signed). This specific CDN returns a 401 if the tokenized URL has been tampered with.

Cache busting should barely ever be required on segment template manifests, especially if it is tokenized, so it would be nice to atleast have the option to disable it.

Note that this was introduced sometime between 1.4.1 - 1.6.0.

Cheers.

[joeyparrish]

@Feenposhleen, we will endeavor to remove cache-busting parameters in Shaka 2, but we do not have a solution yet. The problem was discussed already in #76. In particular see my comments from May 21. If you have any ideas on how to solve the problem described there, please let me know.

In the mean time, we added a feature in v1.4 which will allow you to override this in your application. If you provide a bandwidth estimator and assert that caching will not affect your bandwidth estimations by returning true from supportsCaching().

So this is WAI for v1.x, but I would be happy to have your input on ways to solve BW estimation w/ caching in v2.

[Feenposhleen]

Thank you! I did stumble upon the supportsCaching() method in the interface, but thought it would have other implications and side effects as well. I'm going to try this out and see how it performs.

[Feenposhleen]

Okay, so I poked around a bit. The supportsCaching method seems to be inhibited by the fact that all manifest requests also has the AjaxRequest.parameters.synchronizeClock set to true. The conditional that determines if the URL should be cache-busted always passes if this is set.

So the result is quite the opposite of what we'd like; the video segments doesn't get cache-busted, but the manifest does.

[joeyparrish]

Then this is related to #205. Date-based sync only works when the response is not cached. As it turns out, though, Date-based sync sometimes still fails, depending on the CDN. We plan to abandon Date-based sync in v2.0, but since this seems to differ CDN-to-CDN, we will leave the current behavior for v1.x.

It is difficult to balance caching, bandwidth estimation, clock sync, and CDN-specific behaviors. We are trying to simplify all of this in v2.0 and finally make Shaka cache-friendly.

Until v2.0 is ready, you may wish to customize your build of the library and remove cache-busting entirely. This may have consequences for bandwidth estimation and clock sync, so proceed with caution.

[Feenposhleen]

Okay, fair enough. We've patched this by crudely checking the URL string of a request to determine whether or not it is an .mpd being requested. If so, we disable cache busting.

Thanks for the quick replies as always! Looking forward to 2.0.

[joeyparrish]

@edouardbe: JFYI

[edouardbe]

@joeyparrish, Thanks, I will probably customize locally and look forward to the 2.0 too.
Regards
E.

[joeyparrish]

By popular demand, we're going to offer a configure parameter to disable cache-busting completely in v1.6.2. It should be up on github soon. Please note the trade-offs and issues related to bandwidth estimation before using.

[edouardbe]

Thanks @joeyparrish

I'm using the current JWplayer 7.3.0-beta.1 which integrates the shaka player in version 1.6.1 and I see a difference with my previous tests :
before : the _=date was written after the last queryString parameter
now : the _=date is written before the last queryString parameter

but the problem can not be resolve like that. It was better to let the _=date at the end of the querystring and let us managing with our CDNs how to ignore all the parameters after the security token (our last query string parameter).
By the way, our CDNs did it for us, they now ignore the _=date when after our token.

If the _=date is written before the token, it's worst.

I get the same error with the shaka version 1.5.1 embedded in JWPlayer 7.2.4

About the version 1.6.2, I hope the _=date will be back at the end of the querystring.

Best Regards,

Edouard

[joeyparrish]

@edouardbe You misunderstand. We did not explicitly move the parameter in any version. In Shaka v1.6.2, there is now an option to allow you to remove the _=date parameter (the cache-buster) entirely.