Possibility to get the HTTP status code from the Response Header ?

[ThierryMajutec]

Hi,

Is there any possibility to get the HTTP Status Code from the Response Header in a JavaScript ?
I do not find any related metric in the Time Navigation or other W3C documents.

Thanks,
Thierry

[yoavweiss]

That's not currently possible. Furthermore, if it would be possible, it would probably be limited to same-origin scenarios, or require an explicit opt-in from the origin (like Timing-Allow-Origin)

[yoavweiss]

You can take a look at Network Error Logging and see if it addresses your use case

[nicjansma]

Network Error Logging could help for gathering analytics of failed navigations and failure status codes, but it does have some limitations.

As an example, some of Akamai's mPulse (performance analytics) customers have wanted to understand (and segment/segregate) navigations to 4xx and 5xx pages for their own sites. Since this data is not available via JavaScript directly today, what we've done is have their origin (or the CDN) emit the page's status code as part of the HTML into a JavaScript variable, which our analytics tool picks up and beacons alongside the performance data. This works, but can be a challenge to get this working properly in all cases for all errors. It would obviously be easier if this was available as part of NavigationTiming.

Another downside of relying on just NEL is that it's harder to tie NEL beacons to user sessions. For our performance analytics beacons, each user has a Session ID (persisted with a first-party cookie), which helps tie a user session across multiple page loads. NEL endpoints are just URLs that don't get any credentials or cookies, so a failure report (for 4xx/5xx or other network failures) mid-session will be sent without any context to the user session. If the failure is tied stronger to the user session, we could correlate these origin/CDN failures with business metrics such as conversion rate, which could help websites focus their resource on what to fix.

[bripkens]

@nicjansma brought up a valid point and good context for this ticket. Should we consider re-opening this issue in order to avoid losing this concern?

[JohnRiv]

Just wanted to point out that the current NEL Editor's Draft does have a request_headers member to include specific request headers in the NEL reports, which could include distributed tracing headers to help you tie a NEL report to a specific session.

I don't believe that is implemented in any browser yet though.

[mmocny]

@JohnRiv Thanks for pointing this out! This seems promising and would address the second point that @nicjansma made.

@nicjansma In terms of segmenting navigations to 4xx/5xx pages, could you not get this information from the URLs themselves? Is this because the status of a URL can change over time, and/or for cases where 4xx/5xx error pages are provided inline and not via redirects?

[nicjansma]

@mmocny As a generic analytics provider (Akamai is also the CDN in only some cases), we don't know whether a website's URL is a "good" or or "bad" one -- only if the website somehow exposes that information to us. Often, a website will still provide valid-looking HTML on a 4xx/5xx page so their visitors still get a branded experience, and our analytics tags are often included on those pages.

Your point about the status of a URL changing over time is valid as well.

[clelland]

Re #126 (comment): It does appear that Chrome does not support that yet; I'll look into the status. From a privacy perspective, we'd want to be very careful about exposing some headers, and credentials are certainly sensitive.

OTOH, if reports are sent to a same-origin endpoint, we could send them (and the current Reporting API says that we should), but I don't know if that helps your use case.

[nicjansma]

Related w3c/resource-timing#90