This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
when performing analytics against video content delivered via a CDN it is useful to be able to determine which CDN POP services the customers request. some CDNs include meta information (x-header confirming the CDN, the POP etc) currently there is no way to expose to javascript the additional information in a standard way, so no way to make decisions (enforce affinity etc) or report that information back to a quality logging service
It seems that by necessity this amounts to exposing HTTP headers of cross-origin loads, or would CORS be a required part of this?
I don't understand the request, partly because I'm not familiar with CDN terminology. What's a POP service? What problems are you trying to solve with this information and how would you solve it? Why would the server not be able to provide this information using one of the existing communication methods today?
some CDNs with multiple PoPs (points of presence, nodes or other similar term) can add additional header information to indicate which pop/nodes was actually used to deliver content to the user for instance... the origin for the video file may be in your data center but you distribute it via a CDN with nodes in San Fran, Columbus ,Atlanta, Denver, NYC, and London... and they logic should determine which pop delivers content to a consumer in LA, Detroit or Bonn. For tracking/debug the CDN injects some additional information (either as a header or a cookie) to indicate which POP it was served from / where the user has affinity for the current session. In some scenarios a POP may be having an issue, it may have bad content (old or corrupt) cached or it may simply be that for network logic reasons it's not the right node to affiliate a particular user to ... by allowing the requesting client to access that information (something we do have in Flash, Silverlight etc) and report it back to a QA system it's possible to carry out the same level of debugging or reporting
Ah, I see. What headers would you need, exactly? Would you need this in general for all resources? If there's a single header that we can just expose to the page for all (CORS-)same-origin resources (including those from CDNs), maybe it makes sense to have an object somewhere where you can just get a list of all the URLs and what value they had for that header? This could also be something to consider in the context of the perf WG; maybe they could expose how long it took for each URL to actually be fetched, or some similar data.
some detail on the Akamai use-case at http://webspherehelp.blogspot.com/2009/07/understanding-akamai-headers-to-debug.html though I suspect it would be difficult to produce a definitive list which remains complete so maybe a suggestion would be to list the headers we want to listen to for a specific request (which would tie in with setting the specific pragma headers to get Akamai to share the information to the client) Similar to http://www.w3.org/Bugs/Public/show_bug.cgi?id=14186 this will help to provide more detailed debugging info - especially useful when dealing with video/audio I love the idea of exposing the information (especially around response times) to the Web Timings - especially as we start to venture into the world of adaptive streams (fMPEG, DASH, HLS, Smooth Streaming or where-ever things net out) where being able to see response times, source, response codes etc for each chunk becomes important to get a good idea of the end user quality experience (beyond the simple "did it load or not" knowing if it buffered, how much it buffered, who it buffered for (and where) etc becomes very useful
I had similar feedback from YouTube: "Identifying the server is an essential part in diagnosing streaming issues. Load balancing happens at DNS resolving level, which is not visible to JS. The hostname in the URL could resolve to any of the hundreds of server IPs distributed around the globe. The server might also use HTTP 302 response to redirect a request to another server, and redirects are not visible to JS either. It would help a lot if browsers can export the IP address of the server. If the IP address is not exposed to JS, another way to identify a server is to insert the server id into the video file header and having the client read video header. Does the HTML5 video tag expose an interface for accessing metadata in the video headers?" I had this discussion as part of the video metrics discussion, see http://wiki.whatwg.org/wiki/Video_Metrics and http://www.w3.org/Bugs/Public/show_bug.cgi?id=12399 .
I recommend bringing this up with the WebPerf WG. It seems like something that would be right up their alley, and is not really an HTML-specific feature.
Reassigning to Web Perf for consideration.