> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing [mailto:[email protected]]
> Gesendet: Dienstag, 20. Juni 2017 15:13
> An: [email protected]
> Betreff: Re: Timeouts and other time-related granularity
>
>
> > Am 20.06.2017 um 14:56 schrieb Jim Jagielski <[email protected]>:
> >
> > Most of our time-related directives accept seconds as their
> > parameters, but I'm thinking that allowing milliseconds is
> > likely a better option... From what I can see, most of what
> > would be interesting/useful to change are stored as interval/apr_time
> > anyway, so there would be no real API/struct changes required.
> >
> > Thoughts? Comments?
>
> +1
>
> I would suggest a common duration syntax for better readability and a
> common conversion util function. We can stick to seconds if it is
> just a number, but allow fractions for millis etc. So
>
> "1" is 1 second "0.001" is one millisecond, as is "1ms".
> "1.5m" is 90 seconds, as is "1:30m"
> "1:15h" is 75 minutes
> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms.
> "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc.
We already have such a similar function used in various places of the config:
/**
* Parse a given timeout parameter string into an apr_interval_time_t value.
* The unit of the time interval is given as postfix string to the numeric
* string. Currently the following units are understood:
*
* ms : milliseconds
* s : seconds
* mi[n] : minutes
* h : hours
*
* If no unit is contained in the given timeout parameter the default_time_unit
* will be used instead.
* @param timeout_parameter The string containing the timeout parameter.
* @param timeout The timeout value to be returned.
* @param default_time_unit The default time unit to use if none is specified
* in timeout_parameter.
* @return Status value indicating whether the parsing was successful or not.
*/
AP_DECLARE(apr_status_t) ap_timeout_parameter_parse(
const char *timeout_parameter,
apr_interval_time_t *timeout,
const char *default_time_unit);
Regards
Rüdiger
