in reply to How to make an HTTP request with an equivalent of curl's --max-time?

Where is the documentation for this thing?
  • Comment on Re: How to make an HTTP request with an equivalent of curl's --max-time?

Replies are listed 'Best First'.
Re^2: How to make an HTTP request with an equivalent of curl's --max-time?
by blindluke (Hermit) on Jan 14, 2015 at 07:27 UTC

    For the max-time option? It's in the manpage for curl.

    $ 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. (...)

    - Luke

      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

        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.

        - Luke

        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.