Clarify what constitutes a "downloadable resource"

[JosephPecoraro]

The Introduction says:

The PerformanceResourceTiming interface facilitates timing measurement of downloadable resources.

What constitutes a "downloadable resource"?

• Does an EventSource qualify? (Test Page)
• Does a WebSocket qualify? (Test Page)
• Does a local file: resource qualify?
• What about other schemes like ftp:?
• The spec already has a note that data: should not create an entry.

---

Currently, both Firefox and Chrome are consistent. They create PerformanceResourceTiming entries for EventSource resources, but not WebSocket resources, and not Local resources. I'm unable to test Edge.

I suspect implementations are only focusing on "http" family resources right now. The EventSource example was "http", but the WebSocket resources use "ws:" or "wss:", and local files use "file:". For reference: (Mozilla) and (Blink).

[JosephPecoraro]

On a related note, something I'm encountering in WebKit is the media loads issue range requests to download parts of an individual media resource. What should be the expected behavior here?

[JosephPecoraro]

For many error cases the spec says an entry MAY be included:

If a resource fetch was aborted due to a networking error (e.g. DNS, TCP, or TLS error), then the fetch may be included as a PerformanceResourceTiming object

So maybe there is room to be ambiguous here. It would still be useful to specify what MUST have entries.

[igrigorik]

So maybe there is room to be ambiguous here. It would still be useful to specify what MUST have entries.

It is ambiguous in RT2 and implementations differ in what they expose here. We had long back-and-forth on this in #12. We merged a partial fix for this into L3, but we didn't clearly state there what "downloadable resource" is. The latter bit will be cleared up once we resolve #39, which is also targeted for L3.

So, practically speaking, for L2 it is ambiguous: that's something we acknowledge and have to live with, due to existing implementations out there.

[toddreifsteck]

The spec normative text currently states 'For each resource fetched by the current browsing context, excluding resources fetched by cross-origin stylesheets fetched with no-cors policy, perform the following steps:'

Ideally, there would be tests for each type of fetch and each scheme.
Also, we would ideally exclude blob.

@nicjansma, could you take this one? I think you are uniquely equipped to update based upon data.

[JosephPecoraro]

"For each resource" so is a Media range request considered a resource? (Probably not?)

[yoavweiss]

@igrigorik - going back to this. You say that this remains ambiguous in L2 and will be resolved in L3. As such, should this issue be an L2 blocker?

[igrigorik]

Personally, no I don't think this should be a blocker. We should, if possible, clarify some of the cases that Joseph brought up here, but even with that we won't have full and precise coverage until we solve the underlying issue in L3.

[yoavweiss]

I'll remove the L2 blocker label then (unless other folks object).

[noamr]

The Fetch/HTML/RT integration defines this better. However, resources like EventSource are not yet defined.