window.performance.getEntriesByType('resource') does not include 404 with data
Reported by
msal...@jwplayer.com,
Sep 12
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36
Steps to reproduce the problem:
1. Load a page that requests a status code of 404 but also responds with data (maybe an error message).
2. Open Console in Developer Tools
3. Enter "var urls = []; window.performance.getEntriesByType('resource').forEach(function(r){urls.push(r.name)});"
4. The URL returning the 404 will not be displayed in the list of URLs
What is the expected behavior?
I expect all URLs which return data/communicate with an external service that impact performance should be included regardless of status code.
404's can have an impact on performance and should be listed.
What went wrong?
I have a URL that will return a 404 when it isn't provided the correct URL params, however, it also returns data. Our team will be switching it to be a 400 in the future, but regardless of the status code the entry should be in `window.performance` as it takes time and is loading data via a network resource (no matter how little). The idea that only non-4xx codes effect performance is an incorrect assumption.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 69.0.3497.92 Channel: stable
OS Version: OS X 10.13.6
Flash Version: 31.0.0.108 /Users/michael/Library/Application Support/Google/Chrome/PepperFlash/31.0.0.108/PepperFlashPlayer.plugin
Running the same snippet in Firefox 61.0.2 and Firefox 62 will include the 404'd URL...
Behavior is similar to what is seen in Safari 11.1.2, I will be creating a similar bug with that project.
,
Sep 12
,
Sep 12
Thanks for the bug report! I see the spec says this: "Resources for which the fetch was initiated, but was later aborted (e.g. due to a network error) MAY be included as PerformanceResourceTiming objects in the Performance Timeline and MUST contain initialized attribute values for processed substeps of the processing model." Yoav or Ilya, do you have any context on this maybe statement from the spec? It seems Chrome does not currently expose requests that return errors and additional data.
,
Sep 12
,
Sep 21
We probably need to make the spec clearer on that point: * It's not clear that 404/50X should be defined as aborted fetches * The MAY language makes it tricky to rely on these entries being there or not, so it's be better to enforce it one way or the other.
,
Sep 21
Seems like this was discussed on https://github.com/w3c/resource-timing/issues/12 and https://github.com/w3c/resource-timing/issues/90 We'll need to resolve this as part of L3
,
Sep 24
Thanks, Yoav. I have filed https://github.com/w3c/resource-timing/issues/165 so hopefully this will be discussed during the triage session at TPAC. Setting this ExternalDependency while we wait on the outcome of the spec (per current spec, we seem to be compliant - but we should probably improve the spec).
,
Nov 27
This is currently vague in the spec, and it was decided today that it will be fixed in the L3 spec to specify that 404's (along with other responses) must be reported. Thus I'm marking this as Available, since there seems to be agreement so we just need to fix the implementation at some point.
,
Dec 4
Glad this has made its way through! Is there anything else I may need to do at this point?
,
Dec 4
Nope! This is now Available and the bug will be updated when someone fixes it. I don't have an estimate on when that will be. Thanks for reporting the bug! :) |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by msal...@jwplayer.com
, Sep 12Sorry about the title, I clicked Submit just a bit early it is supposed to say... "window.performance.getEntriesByType('resource') does not include 404 with data"