Two Server-Timing Lines on Every Response: What Our Own Host Sends Twice, and Why Your Parser Shows You One

Every response our own site sends carries the Server-Timing header TWICE. Two separate header lines, not one header with two metrics, and whether you can see both depends entirely on how your HTTP client folds duplicate header names.

I work on OnePassApps, so this is our own host, measured again on 11 November 2026.

One name, two lines

I fetched all 56 URLs in our sitemap over plain HTTPS, one request each, and counted the header lines on the wire instead of the header names in a parsed dictionary. All 56 answered 200. All 56 carried 23 header lines for 22 distinct header names, and on every single one of them the duplicated name was server-timing:

Server-Timing: cfCacheStatus;desc="DYNAMIC"
Server-Timing: cfEdge;dur=18,cfOrigin;dur=35

The first line was byte-identical on all 56 pages. The numbers in the second line changed on every response.

I checked the same thing on a raw TLS socket, before any HTTP library parsed the response, and both lines are physically there in that order.

What your client shows you

The same response reads differently depending on the library:

• Python's email parser, the one urllib and http.client hand you, keeps the FIRST line: message['Server-Timing'] gives cfCacheStatus;desc="DYNAMIC". A plain dict() built from that parser keeps the first one too.
• A dict() built from the list of name and value pairs keeps the LAST one: cfEdge;dur=..,cfOrigin;dur=...
• Node's fetch folds the two into a single value joined with a comma and a space: cfCacheStatus;desc="DYNAMIC", cfEdge;dur=26,cfOrigin;dur=48.
• curl -D - prints both lines exactly as they arrived when it asks for text/html, and prints neither when it asks for */*.

Four libraries, four different answers, one response.

The API host does the same, with one exception

Ten JSON routes on api.onepassapps.com carried 33 header lines for 32 distinct names, with server-timing twice on each. The 404s did too: a route that does not exist came back with 33 header lines and both Server-Timing lines on it.

The exception is the API host's robots.txt. It carried 27 header lines for 27 distinct names, and server-timing appeared ONCE, carrying only the cfCacheStatus line. So the duplicate belongs to the JSON answers, not to every response the edge sends.

The request shape decides whether you get them at all

Same URL, same moment, two different User-Agent strings, one variable changed:

Request	Header lines	Distinct names	server-timing lines
Accept: */*	21	21	0
Accept: text/html	23	22	2
no Accept header	23	22	2
Accept: text/html plus Accept-Encoding: gzip	25	24	2

With Accept: */* the server sends neither Server-Timing line, and the response simply has 21 header lines. That is the same 21-line shape curl gives you by default.

This corrects a post of ours

Our earlier post on this same header said every response carries it in the same two-metric form, and that in two of our probes the header carried cfCacheStatus;desc="DYNAMIC" instead. In every response I measured today the header was carrying both lines at once. The two probes that looked like a variation were the same two lines read two ways, and which one came out depended on how the client folded duplicates rather than on what the server sent.

What I did not measure

• One server, one day, plain HTTPS, no cookies, no JavaScript.
• 56 sitemap URLs on the app host and 13 named routes on the API host.
• The Accept matrix was measured on the home page only, with two User-Agent strings.
• I did not test HTTP/2 or HTTP/3 framing, an edge location other than the one this box reached, or any authenticated request.

Our nine browser apps are at https://app.onepassapps.com/?utm_source=devto&utm_medium=post&utm_campaign=server-timing-two-lines&utm_content=app-link, and every one of their guides is collected at https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=server-timing-two-lines&utm_content=guides-link.

I write here as the OnePassApps team.