> It stores the TIMER_STARTSINGLE time-stamp when it switches to the CONNECT > state for the handle (see https://everything.curl.dev/internals/statemachines) It's a bit complicated to reference the concepts in the linked page to the different time properties available. But reading the source, it seems like there is no reliable way to convert the timestamps to a real world time? It would be nice if that was possible, at least for tracing purposes.
> I can't think of a reason why it should just because of HTTP/2, no. > As you base your observations here on *one* server we can't know what it is > related to! I can't rule out that there's a flaw somewhere here, but I'm not > aware of any. Ok, I found another one which also give a similar result. (It works, it's not that, but the timing does not show up as I expect.) Examples: https://imgur.com/a/BIigCT4 First image is http/1.1, second is http/2. (The timescale is different for the images.) The "wait" is (starttransfer - pretransfer). The "transfer" is (total - starttransfer). For http/2 there is mostly "wait"-time, but there is a /very/ short "transfer"-time following (sometimes ~0.5 ms, but sometimes as low as 50 usec). "wait" is about ~50ms typically. It's only the initial transfers that has time of significance. A short DNS lookup up is done prior to "connect". For http/1.1, the "transfer" is about ~50ms. So it seems to me like the time for the transfer ends up in "wait" instead of "transfer" for http/2, but not for http/1.1. This is the same for both the servers I tested (with http/2). -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
