CMCD: Implement nor and nrr CMCD keys
#1518
Conversation
peaBerberian
force-pushed
the
misc/cmcd-nor-nrr
branch
4 times, most recently
from
9e5b22f
to
2af4c00
Compare
peaBerberian
force-pushed
the
misc/segment-queue-fetcher2
branch
from
823a48b
to
2733245
Compare
peaBerberian
added
the
Priority: 2 (Medium)
peaBerberian
force-pushed
the
misc/cmcd-nor-nrr
branch
from
2af4c00
to
c1bec4d
Compare
peaBerberian
changed the base branch from
misc/segment-queue-fetcher2
to
dev
Based on #1467 We're planning to add CMCD (Common Media Client Data) v1 capabilities to our next release of the RxPlayer v4. This features adds multiple key-value pairs with most request (either from the query string, either from headers) to inform the server-side of the current playback condition from the player which made the request. We were previously missing two keys used for a specific use-case: `nor` (Next Object Request) and `nrr` (Next Range Request). Those two allow the player to anounce which segment it will probably load next so that the server could theoretically prefetch it in advance. Implementing those two means that our CMCD logic needs to be aware of the next segment that will probably be requested after a current one. This is made much simpler by #1467, as now our fetcher logic is aware of the whole queue of segments for a given type (audio/video etc.) in most cases. The main meat of this PR is just computing a relative URL, because that's what CMCD wants (in the name of DoS mitigation, I did not dive into why). I thought we already had that logic somewhere but if we have, I did not find it, so I re-coded and tested it.
peaBerberian
force-pushed
the
misc/cmcd-nor-nrr
branch
from
c1bec4d
to
6d62d54
Compare
peaBerberian
added
Priority: 1 (High)
src/utils/url-utils.ts
Outdated
| if ( | ||
| (baseParts.path[0] === "/" || newParts.path[0] === "/") && | ||
| baseParts.path[0] !== newParts.path[0] | ||
| ) { | ||
| return null; | ||
| } |
There was a problem hiding this comment.
baseURL: http://github.com
newURL : http://github.com/rx-player
The expected relative url should be rx-player right ?
I think it's returning null
There was a problem hiding this comment.
I'll add tests to check
There was a problem hiding this comment.
What I just pushed seems to fix the issue, though it's hard to wrap my head against all those cases
There was a problem hiding this comment.
It "fixes" this particular test case but I'm not sure it's the expected fix, the authority length is always >0 because its the part "github.com" here.
There was a problem hiding this comment.
getRelativeUrl(
"http://github.com/"
"http://github.com/rx-player",
)
this gives "../rx-player" it does not seems right
There was a problem hiding this comment.
the authority length is always >0 because its the part "github.com" here
Yes that was on purpose, because I wanted to return null if for example getRelativeUrl("a/b", "/a/c") is provided.
[...] this gives "../rx-player" it does not seems right
You're right, are you succeeding to see those cases just by reading the code here?
I'm unable to, if it's easier for you to understand the logic I could let you write it.
I added the breaking test
peaBerberian
force-pushed
the
misc/cmcd-nor-nrr
branch
from
4f2a006
to
f9bdfbe
Compare
peaBerberian
force-pushed
the
misc/cmcd-nor-nrr
branch
from
f9bdfbe
to
5d20e83
Compare
Based on #1467
We're planning to add CMCD (Common Media Client Data) v1 capabilities to our next release of the RxPlayer v4.
The CMCD feature, when explicitly enabled, adds multiple key-value pairs with most request (either from the query string, either from headers) to inform the server-side of the current playback conditions as seen from the player which made the request.
We were previously missing two keys used for a specific use-case:
nor(Next Object Request) andnrr(Next Range Request). Those two allow the player to announce which segment it will probably load next so that the server could theoretically prefetch it in advance.Implementing those two means that our CMCD logic needs to be aware of the next segment that will probably be requested after a current one. This is made much simpler by #1467, as now our fetcher logic is aware of the whole queue of segments for a given type (audio/video etc.) in most cases.
The main meat of this PR is just computing a relative URL, because that's what CMCD wants (in the name of DoS mitigation, I did not dive into why). I thought we already had that logic somewhere but if we have, I did not find it, so I re-coded and tested it.