1689730 - Server-Timing HTTP header not shown in dev tools timing panel

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[Yves Goergen [:ygoe]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Send this HTTP response header:

Server-Timing: libLoaded;dur=2.4, contentStart;dur=0.41, contentFinished;dur=0.05, filterStart;dur=2.52, finished;dur=5.73, total;dur=11.11

Actual results:

The timings tab in the network tools for dev tools does not show any server timings, only the usual client network timings. Chrome does it perfectly, even highlights the final "total" entry which is undocumented (just hit it by accident, and I like it). Firefox should support it since version 71. In which version was that removed? The documentation doesn't tell that.

For more information, open that view and click on the help icon at the bottom. The link is broken, you'll have to scroll yourself:

https://developer.mozilla.org/en-us/docs/Tools/Network_Monitor/request_details#Timings

Here's a description of that header:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Yves, thank you for you report!

Any chance you could provide a simple test case we could use to easily reproduce the problem on our machines? That's usually a big help.

Thank you,
Honza

Comment 3

[Yves Goergen [:ygoe]]

That seems to be a bit of a problem. I've created a simple test page that just sets that single header:

https://unclassified.de/tmp/server-timing.php

The thing is, Firefox shows the timings there just fine. So there's a bigger issue that only appears in combination with other circumstances. The page I observe the bug with is non-public so I can't post a link to it. (It is accessible but I don't want to see it linked anywhere. I could send you a link via non-public communication.)

I'll see if I find the time to track this down and find the right combination of headers and/or content to trigger the bug. Until then, all I can say is that the information is sometimes not shown.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Yves Goergen from comment #3)

That seems to be a bit of a problem. I've created a simple test page that just sets that single header:

https://unclassified.de/tmp/server-timing.php

The thing is, Firefox shows the timings there just fine. So there's a bigger issue that only appears in combination with other circumstances. The page I observe the bug with is non-public so I can't post a link to it. (It is accessible but I don't want to see it linked anywhere. I could send you a link via non-public communication.)

Thank you for the update! Yes, your example seems to be working fine.

You can send the link (to your private page) it to my bugzilla email.

Honza

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

There is indeed something broken.

I created this simple test page
http://janodvarko.cz/tests/bugzilla/1689730/
and I don't see any timings

@bomsy, can you please try it, thank you.

Honza

Comment 6

[Yves Goergen [:ygoe]]

I don't see any server timings on your test page (in Firefox).

I also found out that the server timing is missing when I open my website through localhost, but it is indeed displayed when I open it through its public domain. There aren't many differences otherwise (same Apache and PHP version and similar config on both hosts, localhost is Windows, public is Linux). But since the above test page is not on localhost, it could be another cause.

Comment 7

[Hubert Boma Manilla (:bomsy)]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #5)

There is indeed something broken.

I created this simple test page
http://janodvarko.cz/tests/bugzilla/1689730/
and I don't see any timings

@bomsy, can you please try it, thank you.

Honza

Hi Honza,
Thanks for the STR.
i don't see the server timings, did some quick investigations, we don't seem to get server timings in the network-observer.
This is an issue ,I'm not sure if this regressed or has been broken for a while

Thanks

Comment 8

[Cristian Fogel [:cfogel]]

After checking with several builds, prior to the affected one it appears to be something that never made it to Firefox or wasn't working from the get-go.
As per Chrome, the Server Timing is not displayed on Firefox on either builds form 2016->2021 that I've checked on.

In regards to this, clearing the regression fields.
As per the discussion with :bomsy, this might be treated as enhancement; if it's more appropriate.

Comment 9

[Yves Goergen [:ygoe]]

Is it already known what the cause is? I see that info on some sites but not others. Is there a workaround available?

Comment 10

[Hubert Boma Manilla (:bomsy)]

So it looks like the issue is that server timings headers are only parsed for https see https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/netwerk/protocol/http/HttpBaseChannel.cpp#5418. I'm not sure about reason for this.

Valentin, Do you know if there is there any reason?

Comment 11

[Valentin Gosu [:valentin] (he/him)]

Yes, it is specifically restricted to HTTPS (I assume so middle boxes don't interfere with the content, but I don't remember exactly)
See bug 1436517.
Also see docs where it is explicitly stated that's the case.

Comment 12

[Hubert Boma Manilla (:bomsy)]

Thanks Valentin.

Hey Yves,

Is it already known what the cause is? I see that info on some sites but not others. Is there a workaround available?

It works for only https. See Valentin's comment above.

Comment 13

[Yves Goergen [:ygoe]]

Well, so I'm allowed to use it in production but not in development. Do you have SSL certs for your development web server on your local machine? I don't understand why that interpretation and visualisation of the server-provided HTTP response headers is only available for secure transports. What does one have to do with the other? Look, Chrome can do it, so I guess it's perfectly possible on non-secure transports.

Comment 14

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1689730 - Restrict Server-Timing to secure origins r=#necko

Server-Timing was only being parsed with HTTPS. But this is overly
restrictive to developers, so it's better to restrict it to
secure origins which includes http://localhost/

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ba593c7436f6
Restrict Server-Timing to secure origins r=necko-reviewers,dragana

Comment 16

[Natalia Csoregi [:nataliaCs]]

Backed out for failures on test_http_server_timing.js

backout: https://hg.mozilla.org/integration/autoland/rev/757b738131e201a4a69982554e481fee0c9cdb18

push: https://treeherder.mozilla.org/jobs?repo=autoland&revision=ba593c7436f696ef953fb8fecef84ffa818f444a&group_state=expanded&selectedTaskRun=SBOFGEu-Qde_JJbBFGCHgQ.0

failure log: https://treeherder.mozilla.org/logviewer?job_id=336336268&repo=autoland&lineNumber=4693

[task 2021-04-13T10:47:03.697Z] 10:47:03     INFO -  TEST-START | netwerk/test/unit/test_http_server_timing.js
[task 2021-04-13T10:47:03.729Z] 10:47:03     INFO -  adb launch_application: am startservice -W -n 'org.mozilla.geckoview.test/org.mozilla.geckoview.test.XpcshellTestRunnerService$i0' -a android.intent.action.MAIN --es arg8 'const _MOZINFO_JS_PATH = "/data/local/tmp/test_root/xpc/p/ccbb88f0-e2bb-4aa4-a2b3-31bdee4ddee7/mozinfo.json";' --es arg9 -e --es arg0 -g --es arg1 /data/local/tmp/test_root/xpcb --es arg2 --greomni --es arg3 /data/local/tmp/test_root/xpcb/geckoview-androidTest.apk --es arg4 -m --es arg5 -e --es arg6 'const _HEAD_JS_PATH = "/data/local/tmp/test_root/xpc/head.js";' --es arg7 -e --es arg26 '_execute_test(); quit(0);' --es arg25 -e --es arg24 'const _TEST_NAME = "netwerk/test/unit/test_http_server_timing.js";' --es arg23 -e --es arg22 'const _TEST_FILE = ["test_http_server_timing.js"];' --es arg21 -e --es arg20 'const _TEST_CWD = "/data/local/tmp/test_root/xpc/netwerk/test/unit";' --ez use_multiprocess True --es env20 TMPDIR=/data/local/tmp/test_root/xpc/p/ccbb88f0-e2bb-4aa4-a2b3-31bdee4ddee7 --es arg12 'const _TESTING_MODULES_DIR = "/data/local/tmp/test_root/xpc/m";' --es arg13 -f --es arg10 'const _PREFS_FILE = "/data/local/tmp/test_root/xpc/user.js";' --es arg11 -e --es arg16 'const _HEAD_FILES = ["/data/local/tmp/test_root/xpc/netwerk/test/unit/head_channels.js", "/data/local/tmp/test_root/xpc/netwerk/test/unit/head_cache.js", "/data/local/tmp/test_root/xpc/netwerk/test/unit/head_cache2.js", "/data/local/tmp/test_root/xpc/netwerk/test/unit/head_cookies.js", "/data/local/tmp/test_root/xpc/netwerk/test/unit/head_trr.js", "/data/local/tmp/test_root/xpc/netwerk/test/unit/head_http3.js"];' --es arg17 -e --es arg14 /data/local/tmp/test_root/xpc/head.js --es arg15 -e --es arg18 'const _JSDEBUGGER_PORT = 0;' --es arg19 -e --es env9 MOZHTTP2_PORT=40525 --es env8 GRE_HOME=/data/local/tmp/test_root/xpcb --es out_file /data/local/tmp/test_root/xpc/logs/xpcshell-794b02d8-4aab-453e-a7d2-0d39f964558c.log --es env3 XPCSHELL_MINIDUMP_DIR=/data/local/tmp/test_root/xpc/minidumps/ccbb88f0-e2bb-4aa4-a2b3-31bdee4ddee7 --es env2 XPCOM_DEBUG_BREAK=stack-and-abort --es env1 MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1 --es env0 MOZ_CRASHREPORTER=1 --es env7 MOZ_ANDROID_DATA_DIR=/data/local/tmp/test_root/xpcb --es env6 XPCSHELL_TEST_TEMP_DIR=/data/local/tmp/test_root/xpc/tmp/95ce249f-bfeb-458a-9dcf-40bf051b464c --es env5 MOZ_DISABLE_CONTENT_SANDBOX=1 --es env4 MOZ_WEBRENDER=0 --es env19 MOZ_ANDROID_CPU_ABI=x86_64 --es env18 HOME=/data/local/tmp/test_root/xpc/p --es env17 MOZ_LINKER_CACHE=/data/local/tmp/test_root/xpcb --es env16 MOZ_DEVELOPER_REPO_DIR=/builds/worker/checkouts/gecko --es env15 MOZ_CRASHREPORTER_NO_REPORT=1 --es env14 MOZNODE_EXEC_PORT=38815 --es env13 XPCSHELL_TEST_PROFILE_DIR=/data/local/tmp/test_root/xpc/p/ccbb88f0-e2bb-4aa4-a2b3-31bdee4ddee7 --es env12 LD_LIBRARY_PATH=/data/local/tmp/test_root/xpcb --es env11 MOZ_DISABLE_NONLOCAL_CONNECTIONS=1 --es env10 MOZ_DISABLE_SOCKET_PROCESS=1
[task 2021-04-13T10:47:04.026Z] 10:47:04     INFO -  remotexpcshelltests.py | Launched Test App PID=22786
[task 2021-04-13T10:47:04.460Z] 10:47:04     INFO -  remotexpcshelltests.py | Application ran for: 0:00:00.762676
[task 2021-04-13T10:47:04.565Z] 10:47:04  WARNING -  TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_http_server_timing.js | xpcshell return code: 0
[task 2021-04-13T10:47:04.565Z] 10:47:04     INFO -  TEST-INFO took 868ms

Comment 17

[Valentin Gosu [:valentin] (he/him)]

I always forget about Android.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac3eeda873d6
Restrict Server-Timing to secure origins r=necko-reviewers,dragana

Comment 19

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/ac3eeda873d6

Comment 20

[Yves Goergen [:ygoe]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)

Server-Timing was only being parsed with HTTPS. But this is overly
restrictive to developers, so it's better to restrict it to
secure origins which includes http://localhost/

I don't know what a "secure origin" is and I'm wondering how a machine could determine that. Does this also include local network hostnames? I often use the hostname instead of "localhost" so that I can just send over the URL to my smartphone via QR code to test on that device, too.

Comment 21

[Valentin Gosu [:valentin] (he/him)]

(In reply to Yves Goergen from comment #20)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)

Server-Timing was only being parsed with HTTPS. But this is overly
restrictive to developers, so it's better to restrict it to
secure origins which includes http://localhost/

I don't know what a "secure origin" is and I'm wondering how a machine could determine that.

localhost and anyrandomsubdomain.localhost will only resolve to 127.0.0.1 (the local computer)
It is treated as a secure origin even when loaded over HTTP.
Otherwise you need to get a certificate and use HTTPS.

Comment 22

[Yves Goergen [:ygoe]]

Okay, so I can only use this header with Firefox when accessing my development server through http://localhost. Getting a valid certificate for https://mypc or similar names is pretty stupid if at all possible. (Valid means also for Android devices.)

No such restrictions with Chrome. Seems they don't consider this a problem.