Support timing output similar to Curl's -w option

[marklap]

Similar to timing output options in Curl's -w argument, and the data you see using browser debug tools that produce those pretty waterfall charts. A custom requests connection adapter might do the job.

[aseemk]

I'd love to see this, and came here just to file this request.

I personally don't need anything fancy. Just simple timing would be great. (With a way to see only timing, and not the full response body. Perhaps group it with response headers?)

In my case, my colleague discovered that time http ... was super inaccurate, because just running http added several hundred milliseconds. We now do time curl ....

(@marklap: didn't know about the -w argument to curl, thanks. As mentioned, in our case, we want to suppress the response body though, as it's heavy, and we're only interested in the time. Do you know any way to achieve that?)

[sigmavirus24]

Every response from requests has an elapsed attribute that shows the time it took to make the request. Currently 2.3.0 and 2.4.0 only show the time for the initial response, not the time it takes to download the entire response (in the case where the user does not want to stream the body, which is every case in httpie if I understand correctly). There's a bug report for that right now. The -w option would be as easy as printing response.elapsed.

[GuiSim]

Any progress on this feature?

[jorisroovers]

Also interested in having some basic way of getting the total request+response time

[marklap]

I threw this together for fun. It's not awesome but it works and I think it's a bit more accurate than some other attempts (or suggestions).

https://github.com/marklap/httpie-timing

[ghost]

• 1

[doc]

+1

[cristian0]

+1

[WalterInSH]

+1
-w argument is pretty useful

[johan-lejdung]

I'd really see a need for this, are there any plans to implement it?

[plo-]

Any news?

[danieleteti]

News?

[jkbrzt]

Canonical issue: #243

[linpan]

Canonical issue so weird