$ man curl
(...)
-m, --max-time <seconds>
Maximum time in seconds that you allow the whole operation to ta
+ke.
This is useful for preventing your batch jobs from hanging for h
+ours
due to slow networks or links going down. Since 7.32.0,
this option accepts decimal values, but the actual timeout will
+decrease
in accuracy as the specified timeout increases in decimal precis
+ion.
See also the --connect-timeout option.
If this option is used several times, the last one will be used.
(...)
| [reply] [d/l] [select] |
For the max-time option? It's in the manpage for curl. No, not for the self-explanatory option, for the magic url that is immune to regular HTTP GET, that it needs a client induced timeout
| [reply] |
No, not for the self-explanatory option
It would be self-explanatory if its name was max-seconds, that's the problem with most of the _time / -time variables and options. Very few things these days are self explanatory, and, due to insufficient information provided, one often has to figure out the units, the limits, or even the object of a question. ;)
for the magic url that is immune to regular HTTP GET, that it needs a client induced timeout
The OP (probably) refers to the Twitter streaming API - here is the documentation you were (probably) asking for. There are multiple requirements forced upon the client of the stream, like this one below (quote from the docs):
Set a timer, either a 90 second TCP level socket timeout, or a 90 second application level timer on the receipt of new data. If 90 seconds pass with no data received, including newlines, disconnect and reconnect immediately according to the backoff strategies in the next section. The Streaming API will send a keep-alive newline every 30 seconds to prevent your application from timing out the connection. You should wait at least 3 cycles to prevent spurious reconnects in the event of network congestion, local CPU starvation, local GC pauses, etc.
| [reply] [d/l] |
Hi, here's the relevant section from the Twitter documentation:
To connect to the Streaming API, form a HTTP request and consume the resulting stream for as long as is practical. Our servers will hold the connection open indefinitely, barring server-side error, excessive client-side lag, network hiccups, routine server maintenance or duplicate logins.
Not sure what you mean about it being "immune". The issue is that it doesn't stop sending data until something goes wrong or the client terminates it. Why Twitter decided this was a good way to serve up the data I don't know.
| [reply] |